Node interface (was: Re: [jdom-interest] Re: FW: feedback on
phil.weighill-smith at volantis.com
Wed Sep 8 05:30:25 PDT 2004
> > - 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 Weighill-Smith <phil.weighill-smith at volantis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jdom-interest