[jdom-interest] detach() [eg]

[Patrick Dowler]

On 30 April 2001 07:07, Elliotte Rusty Harold wrote:
> At 6:00 PM -0700 4/29/01, Jason Hunter wrote:
> >>  That's secondary to me at this point. I am
> >>  saying, though, that I think detach() on an Element would make me think
> >> it detaches an element from the object detach() is being invoked on.
> >
> >Luckily detach() takes no parameters so if that's your inclination (note
> >it's not my inclination) then you'll have to realize it doesn't work
> >that way.
>
> I think Brett's correct here. The way I explain it to my students is that
> the customary order in OOP is
>
> subject.verb(object)
>
> element.detach() violates that common understanding, especially since
> detach is not a reflexive verb.
>
> I really see no need for detach() anymore. I think that
> parent.removeContent(child) is all that's necessary; and detach() as
> currently written is just plain confusing. If we absolutely must have
> that bit of syntax sugar, then the name should be changed to a verb
> that does commonly operate on it's subject, like element.breakAway()
> or some such; but I really don't think we need it.

The arguments in favour of detach appear to mainly be that it hides about
10-15 lines of case-checking code. It has been proposed that some utility
methods would be useful, probably as static methods in a Util class:

class JDOMUtil {

   public static void move(Element movable, Element newParent) { }

}

I'm not sure if this should throw exceptions, have a return type of boolean to
indicate success/failure, or just silently proceed. It can certainly handle the 
case of a free-floating Element and a typical child element. If the movable
Element is the root element, then this method can do whatever the Document
API allows ( setRootElement(null)? )

Then you can move elements with a single method call and the issue of
whether or not Document always has a root element or not is an issue to
be dealt with in the Document class. They are two separate issues, after all,
and we shouldn't decide the latter just because we want or don't want detach().

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council
Victoria, BC