[jdom-interest] Common interface for "node" classes.

[O'neil, Jerome]

But the problem is that it's already a runtime check if you want to use
lists of child elements in a general way.  They all (to my knowledge, at
least) implement detach (for example.  Because they don't all share a common
interface, I can't call it unless I know the concrete data type.  I have to
check at runtime, and cast appropriately.

List foo = someElement.getChildren();
Iterator foo_iterator = foo.iterator();
while(foo_iterator.hasNext()){
	// How can I tell what kind of thing is coming back 
	// without a specific check at runtime?
	Object node = foo_iterator.next();
	if(node instanceof Element)
		((Element)node).detach();
	
	if(node instanceof ...)
	// Oook.

	// How about...
	JDOMNode node = (JDOM_Node)foo_iterator.next();
	node.detach();
	// Handy-Dandy!!!
}

In fact, I think it would simplify things a great deal if everything did
accept a "Node" as an argument.

--
Jerome O'Neil
Sr. Software Engineer
The Cobalt Group
206.219.8008


-----Original Message-----
From: Jason Hunter [mailto:jhunter at servlets.com]
Sent: Tuesday, April 30, 2002 10:34 AM
To: O'neil, Jerome
Cc: JDOM (E-mail)
Subject: Re: [jdom-interest] Common interface for "node" classes.


Brad's looking into something like this, but there are tricky pieces
everywhere.  detach() for example: if it returns a Node and people want
to do doc.addContent(something.detach()) then that would require doc's
addContent() took a Node so as to avoid the need for a cast.  But a
Document can't accept all styles of Node (no EntityRef/Text/CDATA) so
we'd end up moving what used to be a compile-time check into a runtime
check.

If it was easy, we'd have done it a long time ago.

-jh-

> "O'neil, Jerome" wrote:
> 
> I've been working with JDOM for creating object models for
> semi-complicated XML, and it's been great.  One of the smaller nits
> I'm constantly picking is the lack of a shared type for "node" classes
> like Element and Text.  Common tasks like getParent and detach should
> be specified by a common interface, say JDOMNode or some such thing.
> 
> For example...
> 
> // Methods of particular interest to Jerome for the
> // immediate future. :)
> interface JDOMNode{
>         public JDOMNode detach();
>         public Element getParent();
> }
> 
> class Element implements Serializable, Cloneable, JDOMNode{ .... }
> class Text implements Serializable, Cloneable, JDOMNode{ .... }
> 
> This would mean not having to check for explicit types before casting
> while iterating over child collections, which would be handy-dandy,
> IMO.  I know there was some brief discussion of this kind of thing in
> the list archives, but I don't know if anything was ever decided.  I
> know it starts to tinker with existing interfaces, but I think it's a
> good thing.
> 
> Polymorphism.  It's not just for breakfast anymore.
> 
> Thanks!
> 
> --
> Jerome O'Neil
> Sr. Software Engineer
> The Cobalt Group
> 206.219.8008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020430/cff022a0/attachment.htm