[jdom-interest] Ideas for API changes

[Brett McLaughlin]

> > 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.
>
> Node does not take care of this issue!  You removed from your message my
> discussion of the problem.  Having node *weakens* type checking.
>
> If Element had an addContent(Node) and Document implemented Node then an
> Element could add a Document.  Similarly, if Document has an
> addContent(Node) then Document could add more than one element, Document
> could add Entity objects which don't belong at the Document level.
> Heck, Documents could add Documents.

The reason that I cut out some of that is because I am not arguing that
addContent(Node) neccessarily be added. I'm arguing that a common base-type
simplifies things in many situations. It makes walking a tree much, much
easier. It moves us closer to an XPath implementation that works 100%,
because I know Bob has asked for this before. And for SOME methods, it makes
type-safety better. Additionally, in your example, there is less
type-checking to ensure that an object is an Element, Entity, Comment,
ProcessingInstruction, than to see if it is NOT a Document. There are going
to be checks no matter what, so I don't think saying it weakens
type-checking is accurate, and I think you know it ;-) But I know what you
mean.

>
> So that means with everything accepting Node is we'd still have to do
> lots of runtime checks because not all Nodes are created equal.  I

Not saying that. I'm saying that in some cases, base classes help. I think
in iteration, in tree-walking, in removing possible error-conditions with
LESS code, it helps.

> prefer having the compiler do the checks.  Better to catch errors at
> compile time than runtime.  Plus it makes clear to people that Document
> only accepts certain types of objects, Element only accepts certain
> types, etc.

That's fine. Your whole argument is based on addContent(), and I'm not ready
to take on that argument for now. I'm simply saying a base class is, IMO, a
good thing. Again, my biggest reason is tree walking, which is a pain right
now, and I also see it as being really helpful for XPath. Do you really want
methods that return from XPath methods that return Object? I don't. Talk
about placing burden on the client...

>
> Also, taking a Node interface parameter isn't really safer than taking
> Object because I could still write MyStupidClass implements Node (but
> nothing else) and have it added to any Element even though it's not
> related to XML.  How would you catch that?  By doing exhaustive runtime
> checking within the method?  By just letting this mysterious object be
> added?

Still arguing a point I'm not trying to make ;-)

>
> Another thing:  if Node has getParent() then now Document would have a
> getParent() and that doesn't make much sense.  Methods that don't make
> much sense is one of the largest problems with DOM.

Yeah, that's the one special case I'm unsure about... I wonder, though, if
the value of having getParent() there outweighs the one special case where
getParent() returns null for Document. I'm not sure... but I'm wondering.
That's what we're here for, right? ;-)

>
> More issues: Is DocType a Node?  If so, then Elements could also add
> DocTypes to themselves.
>
> It sounds simple.  It's not.  Even with Node I believe you'd still want
> addContent() to take specific items.  So that advantage is thrown out.

I'll tentatively agree with this, but I don't think that it dillutes my
argument; it might dillute Elliotte's, but I still think it's a good thing
for the other reasons I mention here.

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

>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com