[jdom-interest] Re: Can't we all get along? :) -- [is] getChild() vs.getChildElements()

[Brett McLaughlin]

James Duncan Davidson wrote:
> 
> on 8/1/00 3:25 PM, Brett McLaughlin at brett.mclaughlin at lutris.com wrote:
> 
> >> The point is moot. getChildElement is redundant. The only "legitimate"
> >> children of a parent element are other elements. Where is the
> >> confusion?
> >
> > Entities. The XML specification. The XSLT specification. The XPath
> > specification. And many others. I think what is most notable is that you
> > may be heavy into SGML (I'm sorry ;-) ), but haven't done as much with
> > the XML vocabularies, as that community (I have one foot in it, I
> > suppose) is very used to seeing PIs, Comments, whitespace, text,
> > entites, etc., as children of an Element.
> 
> Ok. So we've got two positions stated:
> 
>     pro getChild(ren):
>         * Succinctness of method name
>         * More distinction between singular and plural forms
> 
>     anti getChild(ren):
>         * All children are not elements in the strict semantic sense
> 
>     pro getChildElements:
>         * All children are not elements in the strict semantic sense
>           according the W3C specs
>         * More accurate name
> 
>     anti getChildElement(s):
>         * getChildElement(s) are too close together in naming for
>           clarity
> 
> Brett said he was happy that most people seemed to be supporting the longer
> names. At this point, it seems that the mailing list is instead moving
> towards deadlock as well.
> 
> So, as an outside observer (gee, I should have let Jas and Brett put my name
> more agressively on the spec so I'd get a core vote, but I talked them out
> of it... :) I agree with Jas that the method names ofgetChild are "nicer"
> (when we were talking about this the other day, my view was that simplier
> was better), but on reading this thread I also agree with Brett that the
> getChildElement names are more technically "correct". And as much as I don't
> really like having some specs having naming tweaks mandated by other specs,
> the Children being more than Elements statement is pervasive in the XML spec
> world and we're pretty much stuck with that. As much as I'd be fine in going
> against that grain, I can understand why Brett and Elliotte want to go with
> that grain. So the impasse has good reasons on both sides. Feh. Time to find
> a compromise.
> 
> So, what can be done? If you look at the use case... and what the programmer
> is saying alound as he types (with various combinations of Child and Element
> naming), you might get the following:
> 
>      "Ok, so I've got this element which is my <target> element. Now, I want
>      to get all of the elements that are below this which are instances of a
>      <task>... I do that with a get_______________() method call."
> 
>   A: "Ok, so I've got this element which is my <target> element. Now, I want
>      to get all of the elements that are below this which are instances of a
>      <task>... I do that with a getChildren() method call."
> 
>   B: "Ok, so I've got this element which is my <target> element. Now, I want
>      to get all of the elements that are below this which are instances of a
>      <task>... I do that with a getChildElements() method call."
> 
>   C: "Ok, so I've got this element which is my <target> element. Now, I want
>      to get all of the elements that are below this which are instances of a
>      <task>... I do that with a getElements() method call."
> 
> A and B are deadlocked. What about C? It works well enough for me as an
> Element has Children, some of which are Elements, some of which are
> Entities, some of which are PIs, some of which are Comments, etc.

In the interest of getting on with it, and avoiding A ;-) I can go with
C (getElement/getElements). Everyone else?

-Brett

> 
> I could live with that? Anyone else?
> 
> .duncan

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org