[jdom-interest] API Inertia

[Kenworthy, Edward]

Have to admit, I find this a little confusing. I really don't see why node
!= Element. Everything else is icing on the Element.

-----Original Message-----
From: Elliotte Rusty Harold [mailto:elharo at metalab.unc.edu]
Sent: 01 May 2001 16:41
To: Jason Hunter
Cc: jdom-interest at jdom.org
Subject: Re: [jdom-interest] API Inertia


At 11:09 PM -0700 4/30/01, Jason Hunter wrote:
>Elliotte Rusty Harold wrote:
>>
>>  I think it would help because the Node interface would have
>>  hasChildren() and getChildren() methods. These would be applicable to
>>  all nodes.
>
>All nodes except: Attribute, DocType, Entity, CDATA.
>

No they're applicable to those nodes too. They just don't do much. 
(Actually I would like to toss CDATA and Entity nodes completely, but 
that's another thread. Even if we don't get rid of them, there's no 
harm to them having these methods.)

>Or are you saying that hasChildren() will just return false for nodes
>which could *never* have children.  That's not very appealing, to have a
>getChildren() method on an object which can't have children.
>

No, hasChildren() returns false for all nodes which don't have 
children. This includes nodes like Attribute that never have children 
and Element nodes that just happen to be empty.

>>  This lets you
>>  walk the tree without caring excessively about the type of each node
>>  in the tree or without a lot of casting.
>
>No casting so long as you don't really want to *do* anything with a
>node.  :-)

For the record you seem to have lost track of everything I've 
proposed for letting nodes do. I guess that's my fault. In a couple 
of messages I only listed those methods that seemed immediately 
relevant. So here it is again. I propose that the Node interface 
declare these methods:

public boolean hasChildren()
public List getChildren()
public String getValue()
public Node getParent()
public Document getDocument()
public Object clone()

In my XInclude processor being able to clone a node without casting 
it would save me quite a few lines.

getDocument() would probably be implemented by walking the tree to 
the root. In fact, we could implement it in Node instead of the 
subclasses, if we made Node an abstract class instead of an 
interface. Off the top of my head I don't see why that wouldn't work. 
In which case, we might as well add equals(), hashCode() and 
toString() to Node to guarantee that subclassers implement them.

>
>>  Frankly I'm amazed that Jason seems worried about typing an
>>  occasional few lines of extra code in the rare case that he needs to
>>  move an element, as evidenced in the detach() thread,
>
>That's putting a burden on the JDOM user.  I want to avoid that.
>
>>  while being
>>  completely unfazed by the huge number of lines doing nothing but
>>  casting and type checking that permeate the JDOM code base today.
>
>That's putting a burden on the JDOM library implementation.  That's
>fine, if it helps the user.
>

It's on the client too. For the last couple of days I've been working 
on an XInclude implementation. I have huge amounts of casting and 
type checking I just wouldn't have if we had a Node interface. I 
suspect a lot of other use cases have this too. In fact, I had pretty 
much concluded that I needed to use DOM instead of JDOM for this 
use-case a while ago, and only picked up JDOM for this problem again 
because a bug in Xerces temporarily stopped my DOM implementation. 
However, that was an implementation bug, not a design flaw in the API.

>>  Everything's a node. By default you visit everything except
>>  attributes (which aren't children) but we can put filters in the
>>  utilities package.
>
>Interesting, while some have everything but Document as a Node you have
>everything but Attribute.  :-)
>

No, Attribute is a Node. It just isn't a child of the Element it's 
attached to. This is exactly how the XPath data model works. It 
confused me the first time I encountered it, but it does make sense 
once you grok it.

-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com