[PEAK] naming.lookup() vs config.lookupComponent()
Phillip J. Eby
pje at telecommunity.com
Tue Jun 22 00:36:58 EDT 2004
At 10:02 PM 6/21/04 -0500, Doug Quale wrote:
>I'm not sure how the cursor gets to be the connection's parent.
When a binding is set, by default it "suggests" to the target of the
binding that the object holding the binding is its parent.
That is, if 'x' is an instance of class 'X', and has a binding 'y', then:
x.y = z
"suggests" to z that its parent is 'x' and its name is '"y"'. Suggesting
only has an effect if 'z' doesn't already have a parent. In this case, 'z'
being the connection, and 'x' being the cursor.
So, it seems that what's happening is that the cursor is a child of the
connection, and the connection is a child of the cursor: an infinite
parenthood loop, and something I didn't realize is actually possible.
Congratulations, you've just found the first 'peak.binding' bug to occur in
quite some time. :) And, not only is it a bug, but it's what I'd classify
as a design error, rather than a stupid typo or editing error, which is
what the majority of my bugs tend to be.
It would appear that I have two choices here: I could have components
check that the component they're adding as their parent, doesn't have
itself as one of the parents. This choice would unfortunately add
significant overhead to most operations involving bindings, since it would
mean iterating over all the parents again.
The other choice would be to make sure that anything that walks over a
component's parents keeps track of where it has been, and raise holy hell
when it finds itself looping. That would fix the "hang" problem, while
hopefully not adding too much performance overhead to the iteration
process. The downside of this approach is that you'd discover your
infinite parenthood loop only *after* it had been created.
On the other hand, it's most likely that the creation of the loop occurred
due to a component being created without a parent, as in your
situation. So the real error occurs long before being detectable. (Note
that it's insufficient to check that a component has a parent, since there
are plenty of legitimate places where you want to create a component and
defer determination of its parenthood.)
I think that probably the best thing to do would be to simply make parent
iteration fail after a predetermined "recursion limit", since it's likely
that component trees of depth 100 or greater (e.g. an infinite parent loop)
are some kind of error, anyway. This would be faster and less resource
intensive to check than trying to track whether a particular component has
already been seen in the iteration process.
More information about the PEAK