Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] The mysterious LeafNode class

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: John Cowan <jcowan AT reutershealth.com>
  • To: elharo AT metalab.unc.edu (Elliotte Rusty Harold)
  • Cc: jcowan AT reutershealth.com (John Cowan), xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] The mysterious LeafNode class
  • Date: Thu, 19 Sep 2002 14:36:15 -0400 (EDT)

Elliotte Rusty Harold scripsit:

> Could you be more specific about what would go where? Are you asking
> for Node --> ParentNode --> Element and Document, with other classes
> extending Node directly? Maybe that makes sense.

Just so, except I do like the name Container for Nodes that, well, contain
things.

> This is, however, possibly the first time in seven years I've
> actually regretted Java's lack of true multiple inheritance.

*moment of awed silence at the sight of a once-in-seven-years event*

> I'd like
> to have separate ParentNode and ChildNode classes extending Node,
> with Document and Element subclassing ParentNode, Element also
> subclassing ChildNode, and the others just subclassing ChildNode.
> dom4j does this with interfaces, but I'm trying to stay away from
> interfaces.

I think that your objections to interfaces are most cogent when, as in DOM,
the classes are hidden and the interfaces are public. When both are
public, interfaces are just useful names for bundles of conventions. If
ClassA and ClassB implement InterfaceA, that just says that you can treat
them somewhat alike if that makes sense, and if not, you can ignore
the very existence of InterfaceA. DOM rams interfaces down your throat.

> I could move some more stuff into Node. Most of the methods don't
> really make sense for attributes though. :-( getNextSibling() and
> getPreviousSibling() could be used for navigation from one attribute
> to the next. The child methods could behave pretty much the same as
> they do for leaf nodes. Maybe that makes sense.

I think it does make sense to put the navigation in Node. It's an open
question, IMHO, whether sibling navigation makes sense for Attributes,
but the *methods* make sense: it's just whether they should return another
Attribute in the list or else null.

That way you don't have to distinguish between containers and leaves when
just navigating, and Container is the proper home of addChild, getChildren,
and all those mutators.

--
We call nothing profound jcowan AT reutershealth.com
that is not wittily expressed. John Cowan
--Northrop Frye (improved) http://www.reutershealth.com




Archive powered by MHonArc 2.6.24.

Top of Page