[PEAK] naming.lookup() vs config.lookupComponent()

[Phillip J. Eby]

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.