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

[Phillip J. Eby]

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 )

Re: [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.


___
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 )

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

[Stefan Bund]

I have already posted this question on the main zope list but have
not received a reply. I hope som Acquisition god is following this
list to shed some light on this matter. 

If there is some kind of definite documentation for the acquisition
machinery especially for how methods are fetched across acquisition, I
would appreciate a pointer to that Documentation. I allready tried to
digest the ZDG (chapter on Acquisition) and the information on the
'AcquisitionMadness' page
. Is there any
more *definite* information on Acquisition apart from the source
code. The problem is, I have a bit difficulty reading the source since
it's an extension class :-(...

But now on to the details of my original question (this is a copy of
my post to the zope list):

My question regards the details of how the contents of im_self of an
acquired method is calculated by the acquisition machinery.

To illustrate this, I will depict an acquisition tree using the
following symbols:

  O-- an acquisition wrapper
-- an acquitsition wrapper named for further reference
  [] -- an object
  --   -- the aq_parent link
  |-- the aq_self link


I will use the following acquisition tree for illustration (it
resembles the tree I have in my application, I just reduced it to
make my point)

A--O--[a]
|  |
|  [b]
|
O--B--O--[c]
|  |  |
|  |  [d]
|  |
|  O--[e]
|  |
|  [f]
|
[g]

(Note: some of the a-g's are identical, but for simpler reference from
the text, i have named them all differently ...)

In this representation, the acquisition order is from bottom to top.
The bottom most object is /A.aq_base/. Acquisition along containment
only produces horizontal lines of acquisition wrappers.

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.

I hope someone can shed light on this subject,

Stefan.

___
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 )