[Zope] Changing Contexts (Was: [Zope] Acquisition? Did I just lose
my Zen?)
Evan Simpson
evan@4-am.com
Wed, 29 Sep 1999 21:31:10 -0500
Toby Dickenson wrote:
> With the rules as they are, an object can always rely on acquisition
> to source its containers first. Think of an object's containers as
> part of it's implementation, and the rules feel right.
[snip]
Agreed, with one exception -- It feels decidedly *wrong* (to me, any way) to
make wrappers for containers we are passing *out of*. Currently, the look-up
order essentially traces the path back from the acquired object to the acquiring
object and then back to the root via the original path. This is perfectly
logical and consistent, based on the way acquisition is defined, but it screws
up hierarchical overriding something fierce.
In the example:
> 'attribute' is looked up in the order[...] z-y-x-root-a-b-c
because we go from c down to the root and then back up to z, and further
acquisition retraces this path.
I would *much* prefer the order z-y-x-root-c-b-a, since this doesn't turn our
client's look-up order completely inside out, but I suppose passing the client
to the acquired method and using it explicitly whenever we want to use its
context is the Right Way to Do It. Any other plan won't avoid hitting the
greatest common ancestor (root, in the example) too early (for the client) or
too late (for the acquiree) to be correct.
It's just so darn easy to get lazy and assume that acquisition will always do
what you want it to without help.