[jdom-interest] detach() [eg]
Kenworthy, Edward
edward.kenworthy at exchange.co.uk
Wed Apr 25 23:47:49 PDT 2001
Hi Brett
Well as the original proposer of the ISE solution I am quite happy with the
idea of having detach on the parent and avoding ever having a document
without a root.
HOWEVER, that change will break all existing code, which is not a good
thing. Replacing the ph with throwing an ISE doesn't.
Edward
-----Original Message-----
From: Brett McLaughlin [mailto:brett at newInstance.com]
Sent: 25 April 2001 18:34
Cc: jdom-interest at jdom.org
Subject: Re: [jdom-interest] detach() [eg]
----- Original Message -----
From: "Jason Hunter" <jhunter at acm.org>
To: <philip.nelson at omniresources.com>
Cc: <jdom-interest at jdom.org>
Sent: Wednesday, April 25, 2001 12:19 PM
Subject: Re: [jdom-interest] detach() [eg]
> > It seems to me we have a growing consensus here.
>
> I think you're overly optimistic.
>
> > 1 - detach becomes the responsibility of the parent and takes an
argument of
> > the content to be detached.
> > 2 - detaching a root element from document will put the document into an
> > illegal state and the IllegalStateException will be thrown by
getRootElement
> > and getMixedContent
> > 3 - after the root element is detached, it will internally be set to
null.
>
> Not quite. Here's where I'm at:
>
> A detach() on a root element removes the root from the document. This
I'm with Elliotte that detach should not be on the Element, but on the
Element's parent. It seems that most people are, from what I've seen. You
changing your opinion on that one yet ? ;-)
> leaves the document in a state without a root (signified not by a null
> but by the fact there's just no Element in its content list; in the
> latest CVS there's no "root" variable anymore). Any later call to
> getRootElement() or getMixedContent() on the Document without a root
> element throws an IllegalStateException. If the user adds a root first,
> the ISE is avoided. If the user doesn't touch the document after the
> detach, the ISE is avoided. With this approach we also have the option
> of having a Document() constructor which will create a doc also without
> a root. This is handy for SAXBuilder. I'm not sure I want to go that
> far though.
I don't. What might make that "easier" makes it "Easier" for folks to create
non-well-formed Documents. I thought that in recent mails, we weren't going
to let non-well-formed things happen? I guess we either need to say "we're
schizophrenic, because we can be" (which is OK, I suppose), or say "we're
always well-formed" and then this dicussion is moot. I'm seeing different
underlying principles being laid out in different threads... I can live with
the ISE, although I'm again in Elliotte's camp with saying don't allow it. I
also think that when the detach() is on the parent, this is more easily
accomplished, as someone is going to expect to have to replace the root when
working with Document. Then again, I was for throwing
NoSuchAttributeException, so there you go ;-)
>
> The summary of this approach is we still enforce well-formedness, but on
> the issue of each doc having a root we enforce it lazily rather than
> aggressively. I lean this way because with a root.detach() I think it's
Well, we enforce it in JDOM code. But you've let loose a Document object
that doesn't have to have a root. So a client can mess what that all you
want. Is calling getContent()/getMixedContent() going to throw an ISE? What
about getProcessingInstructions()? How long do you let a document be used
when it's non-well-formed. I think this is a much more slippery-slope than
is being acknowledged so far.
> extremely likely that people will discard the detaching document and not
> want to be burdened with figuring out how to manage a special case
> detach first before stealing the doc's root. I want the story simple
> for newbies: use elt.detach() to move and elt.clone() to copy.
Doesn't seem right to me, still. elt.clone() makes sense. elt.detach()
doesn't - it doesn't fit into the nice tree model that everyone got fed to
them in CS, doesn't fit into what people expect, IMO.
-Brett
>
> This approach is somewhat similar to the collections
> ConcurrentModificationException where they don't prevent the "bad thing"
> from happening, but do let you know before it affects you.
>
> To rebut Elliotte's argument that ISE is just for threads, you can look
> at the Servlet API where getWriter() throws an ISE if getOutputStream()
> was already called, and vice versa.
>
> > So, can I go back to coding again?
>
> Are you coding on JDOM? I have a pile of stuff!
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
More information about the jdom-interest
mailing list