[jdom-interest] Ideas for API changes

skeens skeens at mobile.rogers.com
Mon Apr 30 05:59:55 PDT 2001

I'm +1 for Tom's idea.  Although there is one problem with it.  How does it deal with child Stings?  Should we have a wrapper class for Strings that implement ElementChild or keep a seperate addContent(String) method?

-----Original Message-----
From: Tom Bradford <bradford at dbxmlgroup.com>
Date: Sun, 29 Apr 2001 18:11:19 -0700
To: Jason Hunter <jhunter at collab.net>
Subject: Re: [jdom-interest] Ideas for API changes

Jason Hunter wrote:
> Because that makes the public API about 50% more complex for almost no
> gain.

How would it be any more complex than it already is?  The marker
interfaces would never have to be exposed to developers, they're only
there to constrain the types of children that you can add to a
container.  The developers would continue using actual classes (Element,
etc...)  Then when your superclass's protected add method gets a child,
it doesn't even have to worry about type checking because the compiler
has already ensured proper typing for that container class.

Every container class has several addContent methods already, so it
would actually allow you to consolidate repetitive code, especially if
common methods such as getParent and getDocument are defined by a Node

In Element alone, there are 5 addContent signatures for classes
(Element, ProcessingInstruction, Entity, CDATA, and Comment) that, if
they were marked with an ElementChild interface and extended Node could
easily be consolidated into 1 addContent(ElementChild) method.

   class ProcessingInstruction extends Node implements ElementChild,
DocumentChild ...
   class Entity extends Node implements ElementChild, DocumentChild,
AttributeChild ...
   class CDATA extends Node implements ElementChild, DocumentChild ...
   class Comment extends Node implements ElementChild, DocumentChild ...

And then in your Element class, you could have one method:

   addContent(ElementChild child) {
      // Specialized checks for any strange cases
      // Where Node's addContent does parent and document ownership

I don't see how that makes things more complex, if anything it
simplifies your code base incredibly, doesn't change the way the user
sees the API at all, and helps them to avoid typing problems just as
easily as your current overload signature method does.

Tom Bradford --- The dbXML Project --- http://www.dbxml.org/
We store your XML data a hell of a lot better than /dev/null
To control your jdom-interest membership:

More information about the jdom-interest mailing list