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

[Brett McLaughlin]

Jason Hunter wrote:
> 
> > 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.
> 
> You misunderstand.  I can use whatever outside resources and opinions I
> want on deciding how to cast my vote.  Now my vote only carries with it
> the weight of one vote (although as a -1 veto that's all the weight it
> needs).

Fair enough on the resources. However, I want to clarify - this is not a
case of /changing/ something (getChild()) to something else
(getChildElements()) as it both (a) appears and (b) you imply by the
veto comment.

I am very certain that we introduced a completely new naming scheme.
Some of those new names matches old ones, some did not. However, I am
just as adamant that the change to getText() is the same as the change
to getChild(). Does that seem weird? Yes, but what I am saying is that
the complete renaming means that each name has to be re-evaluated, as
the entire API changed. It's not a matter of getText() was OK'd, but
getChildElements() wasn't, so we go back to the old. getText() was
agreed upon, getChild() was not, so it still is not resolved.

I really don't consider it a case of keeping it as is, as so many of the
other names have changed - it changes the perception. So I would argue
that we are deadlocked at my +1, your -1 for getChildElements() [or
reverse it for getChild(), either way], and that we have to go to
others. That's why I say this isn't simply a matter of a change or not,
it's a matter of what the new name is.

> 
> > 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.
> 
> That's nothing to be guilty of.  He is top notch, and his opinion should
> weigh into your vote.  :-)
> 
> > 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.
> 
> Following Apache standards, one committer proposes a change, and people
> vote.  It takes three +1 votes and no -1 votes to proceed with the
> change.  (Since we have just two core committers, two +1 votes will
> suffice.)  We've already had a -1 vote here (that'd be me), so there's
> no need for looking to non-core voters.

But it's not a status quo vs. a change situation - it's a completely new
naming scheme, where things do different actions, and new names are
needed in many cases because the connotation has changed with the
addition of other new names.

> 
> For point of reference, on the earlier null vote you and I were not
> fully decided and so looked for outside opinion.  (Which again, is a
> good thing.)

Right, which we've done here, because we're locked. I have been happy to
say that today, when I fully explained my objection, nobody save one has
opted for staying with getChild() - we've had lots of +1 for
getChildElement() and one for getElement() - but it is very apparant
that people are coming around to seeing that the more explicit name is
the better choice. And I would also argue that the assumption that
"Because it's in Javadoc, it's easy to understand" is a false one. We
both know, unfortunately, that it isn't enough. And that people will
still complain about a bad name, regardless of how clear it is. Look at
getElementNS is DOM ;-)

> 
> Here I'm up to be swayed by outside opinion.  Please continue sending in
> opinions (for and against).  But, like I said, I put time into this
> project in the hope that it will make my XML coding life easier and save
> me time and effort.  Anything that goes against JDOM making my life
> easier makes me less inclined to put time into JDOM.

I understand that, and certainly don't want to have that happen - but as
I told you in private, I had to let go of Turbine, a project I
co-founded, because the community wanted to take it in a direction that
was totally different than I wanted. It happens. Additionally, btw, I
don't think that you can argue that type Element on the end of getChild
makes your life less easy - if that typing is that much of a problem,
I'm seriously disappointed ;-)

> 
> I think (like Philip said) a beginner can figure out that "Element
> getChild(String name)" will return an Element, and it makes my code look
> better and gets my job done faster. And since we looked at the
> Collections APIs for whether to return null or not, let me point out
> they shortened the "addElement" name down to just "add".  :-)

It doesn't make your code looks better - it makes it shorter. Most C
programmers would argue that shorter code is better, and be dead wrong.
Let's really not argue that your lack of desire to type equals prettier
code.... come on ;-) Additionally, the collections API takes an object
for add, so obviously add is sufficient. getChild could return any
number of objects based on a simple reading of any XML spec or book, so
it isn't sufficient. Of course, having a JDOM spec would help these
problems.... 

> 
> > 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.
> 
> I just have to say again:  Listen to people you know are smart!  I don't
> think anyone in this community wants you to ignore expert outside
> opinion because the person hasn't contributed patches.  The expert may
> not have a binding vote, but you don't need to shut them out.

I agree - but when you count votes and rate some votes as more important
than others, I take offense - I agree his opinions are valuable,
obviously, but in voting matters, 4 to 3 is simply 4 to 3, not 4 (where
one is James) to 3. It's not fair, and it's just not right... 

anyway, like I said, people are really understanding the issues better
now (I hope in small part because of my mail today) and I am happily
seeing people supporting the longer method name.

-Brett

> 
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

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