[Zope3-dev] Re: ObjectHub should change data structure

[Phillip J. Eby]

At 10:58 AM 6/27/03 -0400, Jim Fulton wrote:
>Phillip J. Eby wrote:
>>Just a thought, but given how much work generally has to be done to 
>>associate an object with its context (i.e., path) in Zope, would it be 
>>really such a bad thing to have objects know who their parent(s) are?
>
>This is a question that I ask myself regularly. :)
>
>Let's look at the pros and cons of using parent references instead of
>context wrappers:
>
>   Pros:
>
>     o Much simpler and much more Pythonic
>
>     o Object references can be direct.
>       This is a big deal.
>
>   Cons
>
>     o Requiring all objects to manage their parents
>       would be intrusive.  Zope 3 wants to avoid any
>       requirements on content objects.
>
>       <wave member="hands">
>       Perhaps this could be mitigated by permanent
>       decorators.  Such decorators might even be
>       used to avoid mixing in persistence in some cases.
>
>       That is, when we add an object to a container and the
>       object isn't parent aware, we put it in a decorator that
>       is and we store the decorator in the container.
>       </wave>

If Persistent supplied a slot for this (_p_container?), it'd be doable 
without any intrusion beyond that already required to support 
persistence.  But perhaps the ZODB list would need to speak to that issue.



>     o We'd sort of like to allow an object to be able to
>       have more than one parent.

Yeah, but we've been sort-of-liking this for what, 5+ years now?  Has 
anybody actually used this yet?  Maybe it's time to call YAGNI on 
it.  (Maybe *way* past time.)



>   OTOH, while I'd like to
>       to be able to do so in theory, it is generally
>       inconvenient in practice.
>
>       For example, synchronizing to the file system is an
>       important feature. The file system is pretty much hierarchical.
>       Synchronizing a non-hierarchical object system to
>       a hierarchical file system introduces lots of complexity.

Sounds even more like multiple parents are a YAGNI.



>     o Parent references introduce circular references
>
>       While Python does have cyclic GC, I'm unsure of it's affectiveness.
>       Collecting cyclic garbage is slower that collecting non-cyclic
>       garbage.

I'm not sure how this is relevant.  ZODB has allowed circular references 
for a long time, and they're certainly not limited to parent-child 
relationships.  ZODB's caching infrastructure is set up to handle this (GC 
at the Python level) already.


>       Similarly, ZODB has cyclic GC, but, for some newer storages,
>       we can automatically get rid of non-cyclic garbage *without
>       packing*.

I don't think this is insurmountable.  Note that if objects manage their 
parent link, they can know when they've been deleted, and thus release 
their contents as well.  This brings up the question of semantics for 
dangling sibling references, in that pointed-to objects will no longer have 
a context.  But then, they do in fact no longer have a context, and it's 
the same semantics as you have now for direct references...

Another possible solution is to exclude parent pointers from reference 
counts, but this would require some enhancements to ZODB.



>     o It's a big change. :)  We have a long history with context
>       wrappers. Then again, that history hasn't always been a happy
>       one.

I'll second that.  :)


>While I hate to revisit so basic an architectural decision, it is
>worth contemplating. I'd be interested in what people think about this.

I'll admit to being biased in favor of parent pointers.  That bias comes 
from years of painful experiences with context wrappers (the old 
Acquisition stuff, mostly, and some versions of my own).  So many things 
are easier when you have explicit parents and management thereof.  For 
example, anything you'd ordinarily "acquire" by walking up to a parent, you 
can also "push" data down to be cached by its children.  When a child 
changes parent, the caches can be discarded.  (I'm not saying you always 
want to do this, but if a child knows about its parentage, it has the 
option of subscribing e.g. to registration events on registries in its 
parents.)

Best of all, links between objects in ZODB are trivial, and getting an 
object's URL is possible.  This would be one less "why the heck doesn't 
this work the way I expect" in Zope 3.