[jdom-interest] detach() [eg]

[Jason Hunter]

> > I prefer the former.
> 
> We seem to have been spending an awful lot of cycles expertly fixing a
> problem that barely exists :-)

True.  Must have all the important stuff done already.  :-)

> In the scenario above what matters is not that the element is detached, it's
> when and only when the application tries to do something with the document
> that the element came from.  Then and only then, it matters if the the
> element was the root element.  Then and only then it matters if the
> application doesn't put new content where the root element was.  In terms of
> use cases I suspect that they probably are in this order.
> 
> 1 - the document goes out of scope without ever being referenced again
> 2 - the application replaces the the root element with setRootElement() and
> uses the document
> 3 - failure case where the use has detached the root element and then
> outputs the document.  This could occur in indirectly related parts of the
> code.
> 
> #3 has got to be in the 1 - 5 % use range, don't you think?  

I think you're dead-on.  I think most people who detach() the root will
be creating a new meta-document of conglomerated XML data and won't give
a hoot about the original document whose root they're stealing.  I doubt
they want to be bothered with the old document.

Elliotte wrote:
> I question the use case. How many times do you want to move the root 
> element of a document? In any case, it seems to me that all we're 
> saying is that when an element is used as the root the Document has 
> locked it and won't let it be moved without a replacement. That seems 
> perfectly reasonable to me.

That reminds me of Windows where you can't rename/move/delete a
directory if any DOS box is currently CD'd into that directory or a
subdirectory.  I prefer Unix where it lets you rename the dir and the
shell might late discoveres it's homeless.

> However,  this is not the problem. The problem is the phantom element 
> JDOM attaches to the root after detaching the root. That seems really 
> ugly and unexpected to me.

Yep, I don't like it either.  I raised the issue initially before adding
the action to the TODO, but I received no feedback.  I figured no one
else cared.  It appears I was wrong.  :-)

> I question the use case. How many times do you want to move the root 
> element of a document? 

I can picture a fair number of use cases where you detach the root.  As
I wrote above, I think it's reasonable to create a meta-document of
conglomerated XML data.  Another idea is that someone might want to take
a chunk of XML String data "<foo>ljdfljsf</foo>" and add it to a
document.  Easy way is to run a parser on the string as if it were a
document, then move the root.  Another brainstorm reason is that you
have a Document that you need to add data to (you take it as a
parameter), and generally you add nodes one by one but sometimes you get
a cache hit and you have the data pre-constructed in another document. 
In that case you'd just move over the root.

It's not that hard to imagine.  But I don't imagine any cases where you
really care later about the "rootless" document.

Phil Nelson wrote:
> 
> If I really intend to dispose of the document, it would annoy me to have to
> set my own bogus root element to do so. 

Agreed.

> I say throw the exception if they
> try to use the phantom root element (or null element).

Hmm...  I've been thinking about this earlier suggestion and I could
definitely live with this.  Basically we'd soften (but not break) the
well-formedness rule so we allow a Document to exist without a root
temporarily but any read on the doc later will throw an exception. 
Hmm...  That'd be convenient elsewhere because then you could say new
Document() and be OK while you got ready to add the root.  Right now we
have an undocumented new Document(null) allowance that builders use to
get this behavior.  It's on the TODO to get rid of it, but it's a little
tricky because it makes better code in the builders to delay adding the
root.  

So, any problem with making the root-existance check deferred?

-jh-