[jdom-interest] children as List

Elliotte Rusty Harold elharo at metalab.unc.edu
Fri Sep 1 06:56:27 PDT 2000


At 2:03 PM +0100 9/1/00, Cameron Smith wrote:
>in reply to Elliote:

>> 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.
>

We wouldn't throw any UnsupportedOperationExceptions! or at least any 
we don't throw now (I don't think we're throwing any now, but I 
haven't checked the source.) Everything we provide now would still be 
provided. The method signatures would be the same. The behavior would 
be the same. The exceptions would be the same. The only question is 
where we put the interface, in Element itself or in a different class.

>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?
>

That Element is more than a List doesn't mean that it isn't a List. 
List is an interface, not a class. It is intended that List will be 
implemented by classes that do a whole lot more than merely manage 
lists. The more I think about it the more I'm convinced, though, that 
logically Element IS A List; that is, it is not simply a relationship 
of HAS A List. In common discussion we talk about the Element's 
children, not the children of the Element's list. Nothing in the XML 
specs talks about a list that's somehow associated with the Element. 
That's a JDOM invention. What is the definition of List if not an 
ordered set of items, the items  normally being called the children 
of the list? Element contains children in a particular order. Things 
that have ordered children are lists. Therefore Element is a list. 
QED.


+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+



More information about the jdom-interest mailing list