[Zope3-dev] Context and Component Lookup

[Martijn Faassen]

Hey,

Butting into a discussion I probably only half understand..

Phillip J. Eby wrote:
> At 05:23 PM 8/6/03 -0400, Jim Fulton wrote:
> >Generally, the dependencies are on interfaces that must be provided in
> >either case. So I don't see anything "reckless" here.
> 
> And that makes it clearer that we aren't quite on the same page.  My point 
> was that if the "foreign" component does a utility lookup on itself, and 
> gets a different result based on who called it, that this isn't a good 
> idea.  For example, this forbids the "foreign" component from caching the 
> result of such a lookup between calls.

If this is an accurate description of what Jim is proposing, this does sound
scary. The foreign component could happily work with its own site's utilities 
and adapters and so on, and when we test it, it works.

Now we use this component from my code, and suddenly it fails because
my code happens to be in a different site, causing a different utility
to be found (the one in my own site). I may not even have supplied this
utility in my site in the first place, causing the code to suddenly
fail.

Isn't it reasonable to be able to use a foreign component in its own
context without worrying how it works and which utilities etc it uses?
It seems to me that in the case where my context affects its operations, I 
need to know far more about its implementation than I may care to know about
(that it even requires said utility).

[snip]
> That's the kind of thing I'm talking about, yes.  Interference with an 
> object's lookup context is "invasion of privacy" aka breaking 
> encapsulation.  The object's author knows more than you do about what his 
> object needs/wants.

> I am saying there should be "freedom of choice" (objects that do lookups 
> can choose where they want to look up from) but no "invasion of privacy" 
> (other objects should not have the ability to reroute an object's lookups, 
> unless they are the object's owner or context, or have been explicitly 
> delegated this responsibility in some other way).

I think that this is a good principle. Such freedom of choice (choosing
to look up in your own context or some caller's context) is easy to 
accomplish if contexts are passed along explicitly. You simply pick
the right context to do the lookup on (context passed by the caller or
your own).

Requiring an explicit context passing however places a heavy burden on
components that Jim would very much like to avoid. One of the basic
goals of Zope 3 is not to burden the developer with a lot of
Zope 3 specific rules when developing a component.

If this is an accurate summary of the quandary, I'd just like to make
the following observation:

If your component is going to do lookups, i.e. use the component architecture,
context does inevitably become a concern of the developer. Thus, if
a developer of a component chooses to do lookups using the component
architecture, context starts to matter to the developer. The developer
really needs to know something about the context the component is 
intended to operate in.

[huge snip]
> >That doesn't tell me anything. What's self? What't to assure that
> >self has a context?
> 
> This is what clued me in to the fact that you're trying to save the Borg 
> joinees from having to have implants.  :)  IMO, if I had to subclass 
> Persistent and I'm importing stuff from zope.component, I've already joined 
> the Collective.  Hook me up a __parent__ attribute or whatever so I can 
> assimilate, already.  :)

All right, I must be understanding this discussion better than I thought,
as Phillip is saying something close to what I just said. :)

[snip lots more]

[Phillip rarely does lookups on the context of another object]

> What I'm curious about here, is whether we differ over a style issue here, 
> or whether there are Z3 requirements that prevent you from using the same 
> approach.

I think this is a very important question.

[Phillip suggests waiting to see what happens after containergeddon]

I support this one. I see now what the fuss on containergeddon is
about, too. 

I can even offer my own use case:

I've had some limited experience with context issues in ParsedXML (zope 2)
and its later port to Zope 3. ParsedXML is a DOM implementation and
its uses context wrappers (acquisition wrappers in Zope 2) to accomplish
DOM parentNode lookups. Unfortunately this is fundamentally broken as 
manipulations like the following can be contrived (and will likely show
up in real code as well):

Take the following XML document:

<doc><e1/><e2/></doc>

Now imagine we have its DOM representation in 'doc', and we do the following:

e1a = doc.documentElement.firstChild # e1 in context a
e1b = doc.documentElement.firstChild # e1 in context b
e2 = e1b.nextSibling # get to e2 from e1 in context b
e2.appendChild(e1b) # now move node e1 in context b to be child of e2
assert e1a.parentNode == e1b.parentNode # this fails!

The DOM standard, for all its flaws, makes a perfectly reasonable
assumption of the behavior trees here. I've thought on occasion
on ways to solve this, but the only solutions concerning context wrappers
were messy hacks that I don't even know would work (ensure there is
only one context wrapper used ever per node, etc..). 

My conclusion was that it would be much simpler to keep explicit
parent references.

(considering the DOM it looks like it may be useful to considering adding
some flexibility Zope 3 so that I can tell it somehow that it should use
parentNode for context lookups, not the default __parent__ or whatever 
containergeddon is using. On occasion 'traditional' context wrappers may
actually be the easiest thing to use and we may be able to tell Zope to use
those too in some way..)

I'm coming at this from a position of ignorance compared to you two, but
perhaps it's useful as some outside input from a developer not as steeped in 
all this. Though of course I've struggled endlessly with context issues in
Zope 2, so I'm not exactly a good example of a completely ignorant developer.
:)

Anyway, from my semi-ignorant perspective, I do find myself agreeing with
Phillip a lot in this discussion, and I worry a lot about the encapsulation 
breakage Jim's proposal implies.

Regards,

Martijn