[jdom-interest] API Inertia

[Jools]

Elliotte Rusty Harold wrote:
> 
> At 11:22 AM -0400 4/30/01, Rosen, Alex wrote:
> 
> >I haven't tried it in either one, but... why would a Node interface help?
> >Assuming you actually want to do something useful with each visited node, why
> >is getting a Node any better than getting an Object? It seems clear that the
> >Node interface would have few (if any!) methods on it, so you'll probably need
> >to cast anyway.
> >
> 
> I think it would help because the Node interface would have
> hasChildren() and getChildren() methods. These would be applicable to
> all nodes. Sometimes hasChildren() would return true, sometimes it
> would return false. Sometimes getChildren() would return a list that
> has members. Sometimes it would return an empty list. This lets you
> walk the tree without caring excessively about the type of each node
> in the tree or without a lot of casting.

Once again we see how talk of using interfaces can blind even someone
as experienced as you Elliotte.

So we have an interface with two methods ? Well that sounds like a 
complete waste of time. 

Have'nt we learnt from the mistakes of DOM yet ?
 
> Frankly I'm amazed that Jason seems worried about typing an
> occasional few lines of extra code in the rare case that he needs to
> move an element, as evidenced in the detach() thread, while being
> completely unfazed by the huge number of lines doing nothing but
> casting and type checking that permeate the JDOM code base today.
> Both positions are reasonable and well argued by Jason. I just don't
> see how he can fit both of them into the same brain at the same time.
> :-)

Personally I grew my hair out __really__ long. It helps to make room 
for this type of stuff ;-) 

If we are talking about trying to replace casting with an interface
which will have an implementation rather than a concreate class, then
well JDOM has just failed all the people that I've taught over the
last year. In fact I'd have to say that it's down to the lack of
interfaces in JDOM that make it so easy to follow.

What would you prefer;

a) Node getChild();

b) Element getChild();

 
> >Also - I would imagine that a lot of tree traversing code only cares about
> >Elements, no? Node would be irrelevent here. And, if you didn't just
> >care about
> >Elements, which things would you care about? Would you want to visit Entities?
> >Attributes? CDATAs? Strings? It's not clear what should be a Node and what
> >shouldn't.
> >
> 
> Everything's a node. By default you visit everything except
> attributes (which aren't children) but we can put filters in the
> utilities package.

Context is everything. It's a Node when it's inside the Tree, but 
what I want is to ask for an Element.

So when I 'get' the Node from the tree, I have an Element. Not a Node.

It's subtle, think about it.
 
--Jools