From: Fred Yankowski <fred@ontosys.com>
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 saw. Cheers, Evan @ digicool & 4-am