"Acquisition Algebra"; interaction of containment and acquisition is confusing
Can anyone help me understand what's going on in the last example of the main "Acquisition" document, <http://www.digicool.com/releases/ExtensionClass/Acquisition.html>? I think I understand how the various "complex expressions" relate to the equivalent expression in terms of the '__of__' operator, except 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))) 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. Can anyone shed some light on this for me? -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
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
Thank you for describing the transformation rules in detail. With those I can mechanically create the same acquisition expression that you get. Working some further examples with this knowledge [and how can I use this knowledge to make mo' money?], I find that given a containment tree like this: a --> b --> c \--> x --> y the access path a.b.c.x.y results in a search order of (y, x, a, b, c) Evan Simpson wrote:
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.
Now, does that bother anyone besides me? Since acquisition is intrinsic and ubiquitous in Zope, shouldn't we be concerned that it is hard to control or predict? -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
From: Fred Yankowski <fred@ontosys.com>
Now, does that bother anyone besides me? Since acquisition is intrinsic and ubiquitous in Zope, shouldn't we be concerned that it is hard to control or predict?
Keep in mind that it is only the *order after containment* that has this problem. For instance, schemes to "skin" a subfolder by changing access paths should ensure that there is always exactly one "skin" implementation in the acquisition path. It is tempting to provide a "default skin" in the containment path, but then you can't override it. Cheers, Evan @ digicool & 4-am
participants (2)
-
Evan Simpson -
Fred Yankowski