[jdom-interest] getChild() vs. getChildElements()

[Brett McLaughlin]

Jason Hunter wrote:
> 
> > etc. It should very clearly be:
> >
> > getChildElement()
> > getChildElements()
> 
> -1
> 
> I had a long explanation written, then my mailer crashed, and it's too
> late and I'm too tired to recreate the message.  But... as someone who
> *uses* the API, I want the method names to remain convenient.  This is
> an API for the programming geeks, not the XML geeks.  They already have
> DOM.

That's a silly argument - Elliotte is an "XML geek" and he came here.
Many others who are "XML geeks" still think DOM sucks. We should cater
to them just as any other. Eventually, everyone is going to know XML,
and have to use an API. Why should we assume all of our users are "dumb
Java users" instead of "smart XML ones?"

> 
> The goal with getChildElement() is to reduce confusion for the new user
> (probably not necessary since we had zero jdom-interest questions about
> this from new users) at the cost of convenience for the regular user.  I
> do see your point, but I'm not willing to give up my convenience.  With
> getChildElement() the method I would use most would have to be named
> getChildElementTextTrim() and about the 10th time I call that method in
> a row (since you call these accessor methods a lot) I'm going to get as
> fed up with JDOM as I was with DOM.  Well, maybe not *that* annoyed, but
> close.:-)

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 ;-) As for your convenience method, I still
am convinced it didn't belong. As it never got discussed or voted on,
I'm a little ... surprised ... it made it into the API. I considered
nuking it yesterday until we had actually followed normal open source
procedures (grin) but thought you might commit hari-kari or something so
held off....

In other words, DOM has methods that don't do what you want, but their
/naming/ is fine. You shouldn't compare a method whose /name/ doesn't
suit you (but still clearly says what it does) with a method that
doesn't do what you functionally want it to. Straw man, and not worth
arguing. In any case, I still think if you were more in the enterprise
space and doing J2EE type things (where EJB required XML, where JMS
required some XML, where JMX required XML), more than the more
servlet-orineted things, then getChild would annoy you a lot more. And I
still submit that these users are "normal" users, not XML geeks.

> 
> I was willing to listen to what other users said and would have been
> swayed had we seen a groundswell of support for the change.  I would

Sure, but the "argument" you stated was like "oh this is the convenient
one and this other is the longer, but maybe more compliant one." That's
hardly a chance for people to figure out the real reasoning. Anyone who
reads XML 1.0, or even the annotated one, or knows DOM, or SAX, or any
other XML API or spec, is going to at some point blow this one. There is
no reason you have given not to do this other than convenience - if it
was a matter of being completely unintuitive with the new names, that
would be one thing, and a good argument against it - but there isn't
that argument. It's purely typing, and that to me is a pitiful platform
;-)

> have figured maybe I was just crazy.  But among the list members who
> commented the majority wanted the name to stay getChild(), 4 to 3.  And
> because among the ones wanting the getChild() name was James Davidson
> (Java/XML guy at Sun, JAXP spec lead, for those who don't know), that
> makes me even more inclined to keep the status quo.

OK, I'm going to say something that hopefully James understands (OK,
James? ;-) ). If someone isn't a committer on this project, we really
can't lend them all this extra weight. I know that I've been guilty as
anyone - for example, I tend to really listen up when Simon St. Laurent
talks, because I think he is top notch in XML land. But votes are first
you and I (on core). Then it's the testers and contribers - Elliotte,
Jools, Werner, some others... and thnose people decide it. If we still
can't get consensus or majority, or whatever, /then/ we go to
non-committers. 

I've just been through a major restructuring of another project because
of this sort of bad habit, and Xerces had some major issues with
non-committers casting votes. The bottom line is that until we ask for
global votes, they /don't matter/. And James will be the first to tell
you this is the case, I know. We haven't even had a vote on it yet,
officially, so people, IMO, have only vaguely said what they want. Once
James is a committer (something I hope he throws some patches in for so
we could make happen), then I'll listen to him equally as well; until
then, it's not fair to the community.

So, if you are against getChildElement() and I am for it, we have an
impasse at the core. So we need the other project /committers/ to vote.
Do you want to write the call for a Vote (with [Vote] in the subject)?
Don't gip me on my advantages, though ;-)

-Brett

> 
> -jh-

-- 
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