[jdom-interest] getChildren() vs getElements()

[Peter V. Gadjokov]

> But element.getElement() -- the singular form -- does look way too
> self-referential.

It does but I think Alex is right - it's pretty hard to use JDOM and not
know that elements contain other elements. 

> > getChildText(String name) is a convenience method anyway, but what
> > would be the problem with renaming it getText(String name) ?  The
> > presence of the parameter should clear up any ambiguity.
> 
> As much as I love the use of such a method, that's just awful.  You
> don't change from parent text to child text retrieval based on a
> parameter.

That's a great reason to skip getText(String name). 


> I like getChild() and getChildren() because it has a certain panache. 
> Matches nicely with getParent().  Easy to tell them apart.  Nice and
> short.  That naming makes me happy in a Zen sort of way.

They are fine names. But they are a little contrary to typical terminology.
I think the fundamental issue is that a JDOM document tries to act as a tree
of nodes, without having a notion of generic nodes while treating Elements a
little differently. The reasoning is obvious and justifyable, most of the
time, you're traversing elements and element is the only non-leaf node type.
How about this alternative - A Document/Element describes a tree of
_elements_. Everything else is not really part of the tree (might be part of
the DOM tree, but JDOM is not DOM), everything else is just a property (or
property list) of an element. So, that means getChild/Children get to stay
since the refer to elements, always. The content thing goes away, a lot of
crazy PartialList magic goes away, things are stored explicitly in
containers appropriate for their type (gives you the option to go typesafe
when Java gets genericity), nothing other than an element is ever referred
to as a 'child'. So if you want to add comment, pi, you addPi, you
addComment, etc. What you lose - you lose the ability to represent
everything an element contains as a mutable list - why is this important
(I'm really asking, everthing I see in the implementation that gets the list
is always instanceof-ing it into components but there is likely a use I'm
not thinking of). If mutability is not important, a List of all sub-pieces
can be constructed on demand. You lose (at least, trivially, it can be
addressed) the ability to retain the exact location of the element text
among sub-elements. It is a lot simpler, though, conceptually. It does let
getChildText make sense. It even makes namespace declarations somewhat
clearer - namespace declarations apply to the descendants of an element
(which, attributes, in this universe, would not be). Now, before someone
points out this is not how XML (or at least DOM) is specified - yes, quite
true - but the current content/child/whatnot muddle doesn't seem much
closer. Did this approach, too, come up and and die a miserable death? The
array of messages on this topic in the archive is daunting.

-pvg