From: Fred Yankowski <[EMAIL PROTECTED]>
> for the very last case, "a.b.c.x".  I just can't follow why the
> equivalent expression isn't
> x.__of__(a).__of__(c.__of__(b.__of__(a)))
> rather than the more complex answer given:
> x.__of__(a).__of__(b.__of__(a)).__of__(c.__of__(b.__of__(a)))

You can expand any access path into an acquisition expression using the
following 3-1/2 rules:

1. Given an unwrapped object 'x', x.child = (child o x)
2. Given a wrapper (self o parent),
  a. (self o parent).child = self.child o (self o parent) if 'child' is
found in 'self'.
  a. (self o parent).child = parent.child o (self o parent) if 'child' is
found in 'parent'.
3. Reduce ((a o b) o (b o c)) to (a o (b o c)) as soon as it appears.

So, a.b = (b o a).  a.b.c = (b o a).c = (b.c o (b o a)) = (c o (b o a)).
Finally, a.b.c.x = (c o (b o a)).x = ((b o a).x o (c o (b o a))) =
   ((a.x o (b o a)) o (c o (b o a))) = (((x o a) o (b o a)) o (c o (b o a)))

> When I run the test cases given in the document I see that the latter
> does match the behavior, but I find that baffling.  In particular, why
> is the effective search order x-a-b-c rather than x-a-c-b?  It almost
> looks like the effective search order could be described as "up
> through the containment heirarchy, then down through the remaining
> acquired path", but I'm not at all sure if that's a valid
> generalization.

Almost.  It's "up through the containment hierarchy, then the rest of it
somehow".  Trying to control or predict the exact search order for any but
the simplest acquisition trees is a dangerous game.  You can read it off
directly from the algebra form, as in (((x o a) o (b o a)) o (c o (b o a)))
=> x, a, b, c (ignoring duplicates), but it's unlikely to be useful, as you


Evan @ digicool & 4-am

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to