No subject

using Text objects which contain a String rather than using String objects
directly. I found bigger performance gains using lazy construction to avoid
List creation (since they are much bigger, more complex, composite objects).
Also take a look at Michael Kay's "tinytree" implementation in SAXON for
some neat ideas on boosting performance.

So in the end I settled for a polymorphic XML tree API instead.


> A more general question is, when would this interface be useful? In
practical
> terms, it seems to me that an interface is only useful if there are times
when
> (1) you can do useful work just by calling methods on that interface, w/o
> having to cast, and

I find this really useful. If your Node interface supports XPath expressions
one day, then you might too. I find I often don't need to cast to different
subtypes, Attribute, Element, Namespace, Text or whatever. I find myself
traversing trees using XPath.

    Node foo = document.getRootElement();
    Node bar = foo.selectSingleNode( "/a/b/c" );
    String name = bar.valueOf( "../d/@name ");


> (2) you don't care what type of object you're dealing with.
> Otherwise, your interface is no better than just using Object.

This depends on how useful your Node interface is I think. If Node is useful
enough then its better than object.

e.g. here's some fairly efficient tree traversal code based purely on Node
(and a Branch which could be an Element or a Document).

    for ( int i = 0; size < branch.nodeCount(); i < size; i++ ) {
        Node node = branch.node( i );
        switch ( node.getType() ) {
            case Node.ELEMENT_NODE:
                ...
                break;
            case Node.TEXT_NODE:
                ...
                break;
            ...
        }
    }


> For example,
> List fulfills these requirements (you usually don't care if it's an
ArrayList
> or a LinkedList).

Agreed - though List is a very useful interface :-)


> For graphical components, you often do care about the type,
> but during painting (for example), you don't.
>
> I theorize that you *always* care about the type of an XML object you're
> working with. In any real world example, you *never* want to treat an
Element
> the same as an Attribute or Comment or ProcessingInstruction. They are
just
> used for completely different things. Of course, this in and of itself
doesn't
> mean we shouldn't use this interface - just because I can't think of an
> example, doesn't mean that someone out there doesn't have a good reason
for
> this. But, I think that there would be a number of ugly things we'd have
to do
> to the JDOM API to work around the above problems (especially the String
> problem), so I think we'd really have to believe that this has substantial
> real-world uses before we do it, and not just hope that it does.

Agreed. I think the String issue is probably the most thorny issue that may
inhibit any kind of Node interface or polymorphism in JDOM.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com