[jdom-interest] children as List

[Patrick Dowler]

On Fri, 01 Sep 2000, Cameron Smith wrote:
> > 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.

There is one big problem with "Element implements List" when it comes to
type-safety. Element would have "add(Object)" which allows anything. We
would have to throw a ClassCastException if the wrong type is supplied.
The compiler will not catch this type of error. 

If we have PartialList do type-checking, we are essentially in the same boat
(runtime exceptions). Manually doing the type check is costly (casting or
instanceof).

To gain compile-time type safety, one has to not use the List interface or
expose the underlying List via getChildren(). It doesn't sound like this is much
of a priority to most of the developers, but it does pay off in the long run.
What it does mean is that Element would have its own API and would have
to provide all the required functionality. This could be a type-safe version
of the List API (the docs just say "if you know List, you know Element")
by having add(Element), add(Comment), etc and doing the right thing inside.
I do not think actually implementing the List interface is the way to go, but
I do think Element should directly provide the features in order to ensure type
safety  - at compile time!

I can already hear people saying "type safety? we don't need no stinking
type safety!" If we do not go this way, in the end we end up with a
lot of error checking  code inside the core classes.

As for the "is a List" vs. "has a List" neither is really correct. Element has
a list (children) and a map (attributes). Do we also expose the attribute
map?

BTW, thsi is certainly a hot discussion... probably the best since
"null vs. exception" :-)

-- 

Patrick Dowler
Canadian Astronomy Data Centre