[jdom-interest] Ideas for API changes

[Jason Hunter]

Brett McLaughlin wrote:
> 
> The reason that I cut out some of that is because I am not arguing that

I was referring to *Elliotte's* post doing the cutting.

> addContent(Node) neccessarily be added. I'm arguing that a common base-type
> simplifies things in many situations. 

That's fine.  I was arguing directly against Elliotte's remark that
addContent(Node) alone was worth adding node.  So I pointed out the
half-dozen reasons we shouldn't have addContent(Node).

> It makes walking a tree much, much easier. 

Maybe.  I'm skeptical.  Since Node can't really have much in it (because
there's not much common across all XML nodes) you still have to do a
cast to your specific object type before doing anything.  You might as
well be using Object.  

What DOM did BTW was create Node interface with pretty much a sum of all
possible methods a node "might" have and so you can always call the
node's methods without casting.  The cost is that for each node half the
methods don't make any sense!  I don't want to see a Node with useless
methods, thus Node has to be very bare bones, thus tree walking might as
well use Object.  Or you just have Document.getIterator() that returns
JDOM objects with each next() call.  That's more the Java Way anyway.

> It moves us closer to an XPath implementation that works 100%,
> because I know Bob has asked for this before. 

Last I heard Bob decided Node wouldn't help.

> And for SOME methods, it makes
> type-safety better. Additionally, in your example, there is less
> type-checking to ensure that an object is an Element, Entity, Comment,
> ProcessingInstruction, than to see if it is NOT a Document. 

So what if I write

JasonsNothing implements Node {
  // getParent impl
}

and add an instance of this class to an Element.  Is that Document still
well-formed?  I'd argue no.

> There are going
> to be checks no matter what, so I don't think saying it weakens
> type-checking is accurate, and I think you know it ;-) 

We'd have to do runtime checks for what is now checked at compile time.

> Not saying that. I'm saying that in some cases, base classes help. I think
> in iteration, in tree-walking, in removing possible error-conditions with
> LESS code, it helps.

I started an afternoon thinking the same thing.  By evening time after
throwing myself at the problem I saw little advantage.

> That's fine. Your whole argument is based on addContent(), 

Because I was talking to Elliotte.  ;-)

> Again, my biggest reason is tree walking, which is a pain right
> now, and I also see it as being really helpful for XPath. Do you really want
> methods that return from XPath methods that return Object? I don't. 

So you do an XPath call to get an Attribute and it returns a Node.  What
are you going to do with the Node?  You're going to cast it to an
Attribute.  What's the win over Object?

-jh-