[jdom-interest] Ideas for API changes
brett at newInstance.com
Sun Apr 29 15:04:17 PDT 2001
> > 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
> 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
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.
O'Reilly Author - Java and XML
> To control your jdom-interest membership:
More information about the jdom-interest