[jdom-interest] A plea for the orphans

[Alex Chaffee]

>  I can think of
> reasons not to store parentage inside each thing where we can do so
> (performance reasons, primarily--it's just a lot simpler to have
> one-way links; maintenance of double links is harder, which means it
> requires more bullet-proofing, which costs, and it still is likely to
> break more often than single linkage),

Another reason is that it closes the door on one possible
implementation of ID/IDREF.  I can imagine an Element appearing many
places in the tree, one time via ID, the rest via IDREF.

However, like I said, this is only one possible implementation, and
I'm not sure it's the right one.  For one thing, it would preclude
regenerating the same XML if the first appearance is not the canonical
one.

Another implementation of ID/IDREF would make a subclass of Element
called Reference that would proxy its calls over to the original
Element, but would be special enough that an XMLOutputter would know
the difference.  Also, a getID() method would not be out of the
question for both Element and Reference (since the ID attribute can
actually have any name, and it's non-trivial to figure out what it
is).  This is a very slippery slope.

> and am willing to accept those
> sorts of arguments (for folks that don't need that behavior, the price
> may be too high), but the fact that it can't be made consistent 'cause
> String is final doesn't much move me.

I am leaning away from getParent() for other reasons, mostly the ones
you mentioned (API simplicity and the annoying nature of
bi-directional links).

For navigation, what's wrong with maintaining a stack and passing it
along, or just using recursion?  Stacks are dead easy in Java: see
java.util.Stack.

I just noticed that Element.getParent() already exists.  How long has
that been so?

 - A

-- 
Alex Chaffee                       mailto:alex at jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/