[jdom-interest] children as List

Cameron Smith cameron.smith at entranet.co.uk
Fri Sep 1 06:03:04 PDT 2000


in reply to Elliote:

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo at metalab.unc.edu]
> Sent: Friday, September 01, 2000 12:56 PM
> To: Cameron Smith; 'jdom-interest at jdom.org'
> Subject: Re: [jdom-interest] children as List
> 
> 
> At 10:51 AM +0100 9/1/00, Cameron Smith wrote:
> >I think its the right decision to present the children of an 
> Element as a
> >List rather than having List-like behaviour in Element itself.
> >
> >This is because:
> >1)  List is almost a 'basic type' now in java: so using it is 'second
> >nature', as opposed to NodeList in DOM.
> 
> This is irrelevant. If we made Element a List we'd still be using all 
> the familiar methods of java.util.List.  We're not proposing to 
> eliminate the use of the List interface, just to make Element 
> implement it. It would not be as unfamiliar as NodeList.
Good point - however, if we make Element a List and throw
UnsupportedOperationExceptions for the ops we don't want to provide, and we
treat a lot of ops this way, we are in fact 'unfamiliarising' users as what
is apparently a List is really not the real McCoy.  On the other hand, this
approach does give us control over what people do to the list - but if we
take it too far it would in fact be clearer to use a 'proprietary' type like
NodeList which simply doesn't have the missing ops.  Either way, though,
whatever List-like interface you end up providing, you could have Element
implement it directly or return it, that's true.


> >2)  If we take the idea of 'pure objects' to the extreme 
> then every class we
> >create which has a variable number of a certain type of 
> object would need
> >its own 'list-style' interface.  Instead, whenever I see a '1-n'
> >relationship between parent and children I think of a 'List' 
> or 'Iterator'
> >interface to provide access to it.
> >
> 
> You could get an iterator on the children. And you could get a List 
> of the children. It would just be a little easier to do so.
Sorry, I wasn't very clear here: what I mean is, do we need to make things
easier to the extent of making an Element, which semantically is more than
just a list, implement List, when we could just return a List?  If a
structure has a collection of children should it always directly implement a
collection-like interface?

> >The main downside of this is the vulnerability of exposing 
> the List to
> >mangling by user code.   However user code which wants to 
> protect itself
> >(and in many cases will /want/ to be mangling the List) from 
> this can use
> >the Collections.unmodifiableList() method.
> >
> 
> The List is still exposed in either version.
Given the target audience of JDom, is that a risk?

> >Another issue was ClassCastExceptions.  I think this is more 
> an issue of
> >whether or not there should be a unified class hierarchy in 
> JDom, so that
> >everything can be safely cast to 'Element', (like Node in 
> DOM) than an issue
> >about where to put List behaviour.
> >
> This can be fixed in either version.
Agreed - so it doesn't affect the argument either way.

cameron smith 



More information about the jdom-interest mailing list