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.