Chris Withers wrote:
Who would be best to ask why it was set up the way it is?
I'm sure there are very good reasons for it but the search order in all but the simple cases is very confusing and not as useful as it could be.
How much more work would it be to implement the following algorithm, regardless of how the actual containment is?
A.B.C.D
Look for D in C, if it's not there, look in B if it's not there, look in A
Someone correct me if I'm wrong here, but... This is a linear search, which is the way acquisition *used* to work. Consider: A / B/ C/ D (A contains B, B contains C and D). A.B.C.D By your desire first look for D in C, then B and then A. But A says "You cannot see Ds". Now, in the linear case, D is found in B, and A is never asked if this operation is permitted. This is a security violation because root policies should be enforced unless they are explicitly overidden further down. Using the system of wrappers, all objects have a chance to enforce proper security. Further, it actually makes *more* sense because the wrappers are built up in the same way you access the object through it's URL. This actually facilitates shared services like security.
It doesn't make Zope any less cool but does make it harder to do _really_ cool stuff with it...
Not from the perspective of the way most development is done. For example, when you want to have your children objects (whatever they may be) be acquireable, you don't need to think about the complexity of the situation, you just make sure you make them accessable in the context *of* you. def foo(self): child = aChild() return child.__of__(self) The Acquisition machinery takes care of everything else for you. Here, we are wrapping child with self, which itself may be wrapped by something else. -Michel