[Zope3-dev] Using parent references rather than context wrappers to represent containment

[Phillip J. Eby]

At 05:33 AM 8/12/03 -0400, Jim Fulton wrote:
>Phillip J. Eby wrote:
>>At 08:30 AM 8/11/03 -0400, Jim Fulton wrote:
>>
>>>I find this unacceptable for component lookup,
>>>as context awareness should not be a prerequisite for using
>>>the component architecture.
>>
>>I thought this too, in PEAK, and originally had a global context, plus an 
>>optional "local" context that was intended for per-thread context.
>>Then I found that the cost of having to explain to people why things 
>>didn't work as they expected, was a higher overhead than what I was 
>>"saving" them by trying to DWIM a context.
>
>I don't know if what you are refering to has anything to do with
>what's being discussed here.
>
>I don't think that anything I've suggeted involves DWIM.

The original per-thread proposal was very DWIM; the "current request" 
proposal is only very slightly DWIM.


>In a seaparate discussion, I've proposed that the single context
>used for a request be determined by the location of the request,
>rather than by the location of the objects involved, unless
>overridden.  This is no more DWIM than using a single global context.

Agreed.  I only wanted to point out that in my experience, having both an 
explicit context *and* a global context turned out to be more DWIMish than 
I had expected it to be.

To put it another way, I discovered that user *failure* is as important to 
user learning as success is, as long as the cause of failure is clear.  In 
fact, failures can be *more* important.  To get an error when an object 
didn't have a context, was much more useful for understanding the 
framework, than for things to most of the time work, and sometimes get 
unexpected results.  Ironically, it also increases a sense of trust in the 
framework, because you get the feeling that, "if I make a mistake, it'll 
let me know, but if it works, it works."


>IMO, the *current* case, there the place to look up components is
>determined by the context, if any, of the first object passed is much
>more DWIMish.  Subtle mistakes in managing context can cause component
>lookup to fail.  I'm not making this up. I've helped people debug this
>sort of problem, which is reminiscent of Zope 3 acquisition problems,
>because, of course, it is am acquisition problem.
>This is exactly the sort of thing I'm trying to avoid.

I agree.  I was only commenting on the fact that what at first appears to 
be "providing a sensible and useful default" to ease the user's learning 
burden, can sometimes turn out to be more trouble than it's worth to just 
be explicit and let the user pay a small learning price up front.

As I believe I mentioned, I don't *know* for certain that this will be a 
problem, which is why I don't strongly object to the current 
proposal.  Also, knowing that I have the option of ensuring "informative 
failure" means it won't cause problems for me personally.  ;)