[jdom-interest] Ideas for API changes

[Brett McLaughlin]

+1. I also like the type-safety and conceptual advantages of either an Item
or Node interface. We can debate the name on another thread ;-)

I also like getParent(), which I actually thought we had discussed earlier.
getDocument() is something that I am -0 on, because I can't think of why I
might need it, but don't have a reason against it, and trust that Elliotte
probably does have a reason for it.

So what are thoughts on a common interface or base class?

-Brett
----
Brett McLaughlin

Enhydra Strategist
  * http://www.enhydra.org
  * http://www.lutris.com
O'Reilly Author - Java and XML
  * http://www.oreilly.com/catalog/javaxml
  * http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0596000162

----- Original Message -----
From: "Elliotte Rusty Harold" <elharo at metalab.unc.edu>
To: <jdom-interest at jdom.org>
Sent: Saturday, April 28, 2001 7:33 PM
Subject: Re: [jdom-interest] Ideas for API changes


> At 3:43 PM -0700 4/28/01, Jason Hunter wrote:
>
>
> >Here's my challenge to you:  Figure out the interface of Item.  Keep in
> >mind that any method declared should be useful across all classes
> >implementing the interface.  And keep in mind the interface should be
> >useful for more than just being a common base interface.  Object is good
> >enough at being a common base; there would need to be extra value.
> >
>
> I'm not sure there needs to be more than that. I think having the
> common type alone because it really strengthens type checking
> throughout the API and makes a lot of code simpler. For instance, in
> addContent() we no longer need to check for seven different types at
> runtime before adding the object. All the checks can be performed at
> compile time. I don't know that this would be significantly faster,
> but it would be conceptually much simpler.
>
> On a similar line, I don't feel Object is good enough as a common
> base class because a method that takes an Object as an argument
> implies to me that it can indeed take any object but our methods
> can't. This seems to cry out for a Node interface. The case where
> methods do take any objects as arguments, and to which me are most
> similar, the Java Collections API, indeed does allow any object types
> as arguments.
>
> However, I do think they're a couple of methods that would be useful
> in the Node interface. At a minimum I'd say getParent() and
> getDocument(). I think we might also want to look at (though perhaps
> in 1.1) a getValue() method which returns the XPath value of a Node.
> This is a very useful thing to have even if you're not using XPath,
> and it is genuinely applicable to all node types, (as opposed to DOM
> nodes, some of which have null values.) I also think we could
> plausibly put hasChildren() and getChildren() in the Node interface.
>
>
>
> --
>
> +-----------------------+------------------------+-------------------+
> | 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