> - There is no common base class for all objects in the document model.  This
> means that serialization and equality methods have to be written somewhat
> piecemeal.  I'm sure that you've considered a common root class.  I'm
> curious why you choose to reject it for the API.

It's a good idea in general, but gets messy when you try to implement 
it.  There's almost no common functionality across all the object types, 
so you'd have a Node interface that's nothing but a blank marker.  That 
not much of an advantage over Object.  In the end we went with Parent 
and Content since there is some overlap between parent classes and 
child/content classes.  Of course, you heard someone this morning say 
they wish we hadn't.  You can't please everyone here.

The reason a "Node" interface is of so much iterest to me is that I can then have JDOM-related type-safety in my own code that utilizes JDOM's classes: you may not see the reason for it within JDOM but not having a common "placeholder" interface for your JDOM classes makes my client code ugly and un-type-safe (having to pass Objects around instead of JDOM Nodes which means anything can be passed to my methods and that we have to rely too heavily on javadoc and runtime debugging to "guide" the usage of our code).

I'm hoping it's not too late to add this sort of placeholder interface to JDOM 1.0 (after all, "all" you have to do is create the interface, check and replace the relevant Object usages in your JDOM method signatures and method bodies, make your relevant interfaces and classes extend/implement this interface and away we all go!). There's no reason why you can't make Parent and Child co-exist with a Node interface.

What do you think?

Phil :n.

-- 

Phil Weighill-Smith <phil.weighill-smith@volantis.com>

Volantis Systems

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@(protected)