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

[Alex Chaffee]

Wait a second.  The +1s are coming fast and furious but...

I think getChildElements() is too verbose and also redundant.  Of
course it's a child element; what other kind of element would it
return?  A parent element?  A cousin? :-)

getElements() is not ambiguous.  It doesn't imply that it recurses any
more than getChildren() implies that it recurses.  Once you accept
that an element can contain elements, it is not confusing (it only
sounds self-referential, but it's not).

The issue is terminological: there are many "children" of an element,
but only some of them are elements.  Thus getElements() should return
the children that are elements, getAttributes() should return the
children that are attributes, and so forth.


So:

getChildren() should be renamed getElements() 

(*not* getChildElements(), unless there's a corresponding change to
getChildAttributes())

Likewise, getChild() should be renamed getElement().

addChild(...) is already deprecated so it's not a problem, though I
actually believe addChild() is better than addContent() ("content"
implies "text content of this node" not "some sort of child of this
node")

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.

Then removeChild() / removeChildren() / setChildren() should be
removeElement() / removeElements() / setElements()

Following this logic, "getMixedContent()" should be renamed
"getChildren()" but that would be very confusing at this stage.  I'd
still vote +1 for it but it would cause a deluge of misguided bug
reports.

*That's* the proposal.  Not piecemeal, changing one name a dozen
times.  The whole kit and kaboodle.  We accept, once and for all, that
a child is not the same as an element.

Or not :-)

 - Alex


On Thu, Sep 14, 2000 at 05:49:52AM -0700, Alex Chaffee wrote:
> 
> Wasn't there a discussion a few months ago about renaming
> getChildren() to getElements()?  This Solomon-like solution was
> provided by somebody smart, I think James.
> 
> Recap:
> 
> element.getChildren()
> 	ambiguous; implies that it gets Attributes etc. :-(
> 
> element.getChildElements()
> 	too long to type :-(
> 
> element.getElements()
> 	brief; no way it can be misinterpreted :-)
> 
> Was this just forgotten, or was there a reason to keep getChildren
> that I missed?
> 
> (We could deprecate getChildren for a few months before the 1.0
> release to allow migration.)
> 
>  - Alex
> 
> P.S. This is orthogonal to the current "Element implements List"
> discussion.  BTW, I think it should not implement List, for this very
> reason: there is an ambiguity as to what the members of that list
> would be (elements or mixed or elements+attributes or ...)
> 
> 
> -- 
> Alex Chaffee                       mailto:alex at jguru.com
> jGuru - Java News and FAQs         http://www.jguru.com/alex/
> Creator of Gamelan                 http://www.gamelan.com/
> Founder of Purple Technology       http://www.purpletech.com/
> Curator of Stinky Art Collective   http://www.stinky.com/
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Alex Chaffee                       mailto:alex at jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/