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

[James Duncan Davidson]

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.

I could live with that? Anyone else?

.duncan