ILocation rather than IContained? (was Re: [Zope3-dev] Using parent references rather than context wrappers to represent containment)

[Phillip J. Eby]

At 06:24 AM 8/12/03 -0400, Jim Fulton wrote:
>The idea is that ILocation is the union of *a* physical hierarchy
>and adaptation.  Persistent objects have a physical location. Adapters
>have a location based on the persistent objects that they adapt.
>
>Note that a system that didn't use a file-system metaphor could conceivably
>use some model of physical location other than containment.
>
>Also note that that even in Zope we want to use something that is a little
>more than containment. For example, technically, a site doesn't strictly 
>contain
>it's site manager, since the site manager is outside of content space. Put
>another way a __container__ need not be an IContainer and, even if a
>__container__ is an IContainer, the thing with the __container__ attribute
>that points to the container need not be *in* the container.

Sounds just like PEAK, in that 'someComponent.getParentComponent()' is not 
necessarily an object that holds a reference to the someComponent.

I'm not clear, though, on why you would mix this with adapters.  In PEAK, 
sometimes an adapter will use its adaptee as a parent, but odds are roughly 
even that it will have a different parent, and if it's a "view" adapter, it 
is definitely going to use its containing view as its parent.


>   The physical hierarchy
>is slightly bigger than the containment hierachy. The containment hierarchy is
>a subset of the physical hoerarchy.

Yep.  As long as you're not saying that adaptation relationships *must* 
follow the context hierarchy, or vice versa.


>I think that location is a better concept than containment. It is narrow 
>enough not
>to get confused with other sorts of associations between objects but is 
>broad enough
>to include adaptation.
>
>Thoughts?

One nice thing about having such a hierarchy, is that it's easy to do 
algorithms of the form:

for component in iterParents(context):
     something = adapt(component,IThingINeed,None)
     if something is not None:
          # do the lookup or perform the behavior
          # and break out if I just want the first thing
          # (assuming I got the result I wanted)

The PEAK IComponent interface is effectively a combination of interfaces for:

* Being a member of a hierarchy (getParentComponent(), getComponentName(), 
and uponAssembly())
* Providing configuration data, akin to your IServiceService suggestion 
(_getConfigData())
* Attachability (setParentComponent())
* Configurability (registerProvider())

And, adapt() is used to obtain implementations of these interfaces, so that 
the component APIs can accept any object.  Objects that don't implement 
(and can't be adapted to) the hierarchy interface are considered to have 
'None' as a parent, meaning that they are root components.  If a root 
component doesn't implement or adapt to IConfigurationRoot, then using that 
component as context for certain kinds of lookups will fail.