[Zope-dev] im_self of methods accessed via non trivial acquisition

[Phillip J. Eby]

At 09:42 AM 1/18/02 +0100, Stefan Bund wrote:

>A--O--[a]
>|  |
>|  [b]
>|
>O--B--O--[c]
>|  |  |
>|  |  [d]
>|  |
>|  O--[e]
>|  |
>|  [f]
>|
>[g]
>
>...
>
>let /m/ be a method of the objekt /f/. The expression of interest is
>
>     x := A.m
>
>I would expect /x.im_self/ to be an acquisition wrapper C
>
>     C := A.f
>
>where (as far as i understand the rules of acquisition)
>/C.aq_parent == A/
>
>But instead displaying  /x.im_self/ yields the acquisition tree rooted
>at /B/ !!
>
>I find this a bit disturbing. My question: 'Is it a *bug* or a
>*feature*?'. I hope, I made my point clear.

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.