[jdom-interest] Ideas for API changes

[Tom Bradford]

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
class.

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
      super.addContent(child);
      // Where Node's addContent does parent and document ownership
checks
   }

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