[jdom-interest] Re: jdom-interest digest, Vol 1 #188 - 6 msgs

[Jason Hunter]

> Wouldn't the problem go away if we play by the following rules?:
> (1) An element can find its document iff it is an ancestor of that
> document.
> (2) An element cannot be added to another document unless the 
> element to be added cannot find its document nor its parent.

Well, I'm not sure I understand you 100%, but you don't need to worry
about "finding its document" because a doc can have only one root.

> To go about implementing these rules...
> (1) clone/copy will return the copy such that it has no parent and
> cannot find its document

I'd remove the "and cannot find its document", but yeah.

> (2) removing an element works like clone/copy except that it's 
> the same instance

Yep, no parent.

> (3) adding an element must check that the element has no parent and
> cannot find its document

The "No parent" rule is already checked.  We'd add a check that the
element has no ancestor that is itself.

Implementing isn't all that hard.  The big question is, are we OK with
every add (even when initially building the document with SAXBuilder)
doing this sanity check?  

We have a fundamental pull here (and with PCDATA checking and name
checking and so on) between writing a fast and lightweight
implementation that lets you do stupid things but trusts you won't, and
writing an implementation that doesn't let you make stupid mistakes and
will take time making sure you don't.  Each piece isn't a terrible time
sink, but overall they'll add up.  Do we want every add to require
multiple method calls and pointer comparisons?

The right solution is for JDOM somehow to support both worlds.  Because
if it doesn't, then someone (could be me) has an incentive to fork and
write a version without all the checks that runs faster.  How to support
both "sanity checking" and "non-sanity checking" version is the real
trick.

-jh-