<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [jdom-interest] Common interface for "node" classes.</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>List foo = someElement.getChildren();</FONT>
<BR><FONT SIZE=2>Iterator foo_iterator = foo.iterator();</FONT>
<BR><FONT SIZE=2>while(foo_iterator.hasNext()){</FONT>
<BR> <FONT SIZE=2>// How can I tell what kind of thing is coming back </FONT>
<BR> <FONT SIZE=2>// without a specific check at runtime?</FONT>
<BR> <FONT SIZE=2>Object node = foo_iterator.next();</FONT>
<BR> <FONT SIZE=2>if(node instanceof Element)</FONT>
<BR> <FONT SIZE=2>((Element)node).detach();</FONT>
<BR>
<BR> <FONT SIZE=2>if(node instanceof ...)</FONT>
<BR> <FONT SIZE=2>// Oook.</FONT>
</P>
<P> <FONT SIZE=2>// How about...</FONT>
<BR> <FONT SIZE=2>JDOMNode node = (JDOM_Node)foo_iterator.next();</FONT>
<BR> <FONT SIZE=2>node.detach();</FONT>
<BR> <FONT SIZE=2>// Handy-Dandy!!!</FONT>
<BR><FONT SIZE=2>}</FONT>
</P>
<P><FONT SIZE=2>In fact, I think it would simplify things a great deal if everything did accept a "Node" as an argument.</FONT>
</P>
<P><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>Jerome O'Neil</FONT>
<BR><FONT SIZE=2>Sr. Software Engineer</FONT>
<BR><FONT SIZE=2>The Cobalt Group</FONT>
<BR><FONT SIZE=2>206.219.8008</FONT>
</P>
<BR>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Jason Hunter [<A HREF="mailto:jhunter@servlets.com">mailto:jhunter@servlets.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, April 30, 2002 10:34 AM</FONT>
<BR><FONT SIZE=2>To: O'neil, Jerome</FONT>
<BR><FONT SIZE=2>Cc: JDOM (E-mail)</FONT>
<BR><FONT SIZE=2>Subject: Re: [jdom-interest] Common interface for "node" classes.</FONT>
</P>
<BR>
<P><FONT SIZE=2>Brad's looking into something like this, but there are tricky pieces</FONT>
<BR><FONT SIZE=2>everywhere. detach() for example: if it returns a Node and people want</FONT>
<BR><FONT SIZE=2>to do doc.addContent(something.detach()) then that would require doc's</FONT>
<BR><FONT SIZE=2>addContent() took a Node so as to avoid the need for a cast. But a</FONT>
<BR><FONT SIZE=2>Document can't accept all styles of Node (no EntityRef/Text/CDATA) so</FONT>
<BR><FONT SIZE=2>we'd end up moving what used to be a compile-time check into a runtime</FONT>
<BR><FONT SIZE=2>check.</FONT>
</P>
<P><FONT SIZE=2>If it was easy, we'd have done it a long time ago.</FONT>
</P>
<P><FONT SIZE=2>-jh-</FONT>
</P>
<P><FONT SIZE=2>> "O'neil, Jerome" wrote:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I've been working with JDOM for creating object models for</FONT>
<BR><FONT SIZE=2>> semi-complicated XML, and it's been great. One of the smaller nits</FONT>
<BR><FONT SIZE=2>> I'm constantly picking is the lack of a shared type for "node" classes</FONT>
<BR><FONT SIZE=2>> like Element and Text. Common tasks like getParent and detach should</FONT>
<BR><FONT SIZE=2>> be specified by a common interface, say JDOMNode or some such thing.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> For example...</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> // Methods of particular interest to Jerome for the</FONT>
<BR><FONT SIZE=2>> // immediate future. :)</FONT>
<BR><FONT SIZE=2>> interface JDOMNode{</FONT>
<BR><FONT SIZE=2>> public JDOMNode detach();</FONT>
<BR><FONT SIZE=2>> public Element getParent();</FONT>
<BR><FONT SIZE=2>> }</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> class Element implements Serializable, Cloneable, JDOMNode{ .... }</FONT>
<BR><FONT SIZE=2>> class Text implements Serializable, Cloneable, JDOMNode{ .... }</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> This would mean not having to check for explicit types before casting</FONT>
<BR><FONT SIZE=2>> while iterating over child collections, which would be handy-dandy,</FONT>
<BR><FONT SIZE=2>> IMO. I know there was some brief discussion of this kind of thing in</FONT>
<BR><FONT SIZE=2>> the list archives, but I don't know if anything was ever decided. I</FONT>
<BR><FONT SIZE=2>> know it starts to tinker with existing interfaces, but I think it's a</FONT>
<BR><FONT SIZE=2>> good thing.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Polymorphism. It's not just for breakfast anymore.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Thanks!</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> --</FONT>
<BR><FONT SIZE=2>> Jerome O'Neil</FONT>
<BR><FONT SIZE=2>> Sr. Software Engineer</FONT>
<BR><FONT SIZE=2>> The Cobalt Group</FONT>
<BR><FONT SIZE=2>> 206.219.8008</FONT>
</P>
</BODY>
</HTML>