Not sure if I dare to tread on this thread but....
> As I said, convenience in naming has almost zero sway on me -
> especially
> since we are still at only 15 or so characters. If it's that
> frustrating, use cut/paste ;-)
I spoke in favor of getChild over getChildElement. Typing convienience has
no sway for me either. Both my IDE (Visual Age) and favorite text editor
(GVim) make this a non issue because of completion. For me, it's reading of
the code that sways me. I don't want to scroll right and I dislike
autowrapped code on long lines so I usually turn that off.
There is NO ambiguity on
public Element getChild()
getChildElement is redundant because of the return value. To avoid a line
like
Element myNestedElement =
getChildElement("somename").getChildElement("somename").getChildElement("som
ename")
I prefer
Element myNestedElement =
getChild("somename").getChild("somename").getChild("somename")
I would really like get<notSure>("somename/somename/somename") in which
case the type returned will be obvious to the programmer in the XPath. In
this case, I would probably no longer use getChild on nested elements.
Even while editing this email the first one wrapped.
On getChildElements a better case could be made for the longer name since
Element is not in the return value. Still, with any List, you must read the
doc to find out what sort of items it may contain so you can correctly cast
items retreived. So, once again, I would opt for getChildren().