At 01:12 PM 1/18/02 +0100, Stefan Bund wrote:
Phillip J. Eby [EMAIL PROTECTED] writes:
Method rebinding is done only when an item is retrieved from the aq_self
side, and only if im_self points to aq_self. If these conditions are met,
a new binding is created which points to the acquisition wrapper.
This is a feature, not a bug. If you rebind im_self on the aq_parent side,
and your method assigns a value to an attribute of self, it will be
assigned to the wrong object! It is safe in your example to bind m.im_self
to B, because B.aq_base is f, the true self of m. But it is not safe to
bind m.im_self to A, because A.aq_base is g -- another object altogether.
I guess another way to look at it is that a method retrieved from an
acquisition-wrapped object will always meet the condition that
method.im_self.aq_base is the original object the method was retrieved
from. This ensures that the method simply works with an
acquisition-wrapped version of its original self.
Of course, im_self cannot be A, that would be wrong, but as far as I
understand, it could be a *new* acquisition wrapper, something like /B
o A/ or even /[f] o A/:
C--A--O--[a]
| | |
| | [b]
| |
| O--B--O--[c]
| | | |
| | | [d]
| | |
| | O--[e]
| | |
| | [f]
| |
| [g]
|
B--O--[c]
| |
| [d]
|
O--[e]
|
[f]
(that's what I refer to in the definition of /C/). So if /C/ is one of
the aforementioned new wrappers, /C.aq_base/ is indeed [f] and
therefore, /C/ would be safe as im_self?
Hmm. Is there another reasun, why method rebinding works the way it
does (returning a subtree and not a new acquisitionwrapper like
described above) or am I completely amiss?
Beats me. I guess nobody's asked for the feature, and in any event it
requires global knowledge of the tree structure that would be very
difficult to code. The current behavior is a rule that is applied locally
at each acquisition wrapper, and the wrappers don't know what wrapper is
pointing to them, so it's really not practical for them to try and do
something that smart.
It may also be that what you're asking for is a bad idea, in which case Jim
Fulton can probably explain why. :)
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
