[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