[jdom-interest] Why don't Comment, Element, Text, etc extend common jdom object?

[bob mcwhirter]

I'm not disputing that all.  My conflict arises in that we have a
method called 'detach()', and the documentation for it seems to
imply it's what you'd use to detach an element.  But, there's 1 case
where you don't use it, but instead use Iterator::remove(). 

With JDOM's 80/20 rule, it seems like 80% of the folks want to detach
nodes while iterating, and many of them are coming across this problem.

It's related to the fact that the lists are 'live', which also confuses
people on a daily basis.  

Possibly just a no-op subclass/subinterface of List like ElementList
could be returned.  Extra documentation could describe the 'liveness'
of the list, and the contract of using Iterator::remvoe() to actually
remove items from your document.

/** The JDOMList is a <b>live</b> list.  To remove things from
 *  your document, use {@link Iterator#remove}.
 */
public interface JDOMList extends List
{
	// intentionally left blank
}

class FilterList implements JDOMList
{
	// normal implementation
}

Wouldn't break code, as we'd still have the List in the hierarchy,
but would give us an extra place to make the behavious painfully
clear.

	-bob



On Tue, 28 May 2002, Gordon Tyler wrote:

> ----- Original Message -----
> From: "Elliotte Rusty Harold" <elharo at metalab.unc.edu>
> 
> 
> > >Can anyone think of a way for either detach() or Iterator::remove() to be
> > >legal?
> >
> > DOM tree walkers and node iterators have no problem with this use
> > pattern. However, they don't use the collections API. Off the top of
> > my head, I can't see how to make this work without ditching the
> > Collections API and rolling our own; but then I don't really know a
> > lot about the Collectios API so maybe it's possible.
> 
> I always thought the whole point of the JDOM API was that it used standard
> Java APIs like Collections.