W3C home > Mailing lists > Public > public-webapi@w3.org > December 2006

Re: Selectors API naming

From: Kelly <lightsolphoenix@gmail.com>
Date: Wed, 20 Dec 2006 19:57:50 -0500
To: Chris Wilson <Chris.Wilson@microsoft.com>
Cc: Robert Sayre <sayrer@gmail.com>, Martijn <martijn.martijn@gmail.com>, Jim Ley <jim@jibbering.com>, Ian Hickson <ian@hixie.ch>, Dave Massy <dave.massy@microsoft.com>, Anne van Kesteren <annevk@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Message-Id: <200612201957.51628.lightsolphoenix@gmail.com>

I know it's kind of late in the game to be discussing this, but I prefer 
getElementBySelector(), simply because it matches what has come before.  In 
all seriousness, you'll hear people complain about having to use select as 
the function name, claiming that is too long.  If people want shorter names, 
they'll ultimately alias them.  If people want longer names, they'll 
ultimately alias them.  Therefore, it is much better to follow the 
convention, regardless of whether it's considered "bad" or not.  If there's 
no convention, you get what amounts to a completely random arrangement of 
functions, which will lead to people having to look up the function names 
whenever they want to do anything.

In fact, I'd be willing to bet the vast majority of complainers are people who 
code in ECMAScript and only ECMAScript; if I were writing such a library, I'd 
use get____ simply because it's a convention I like to follow, from Java.  It 
returns something, therefore it should be get____ at the very least.

On Wednesday, December 20, 2006 7:23 pm, Chris Wilson wrote:
> ?  I never claimed there were technical problems with "matchAll" or
> "select" either - just that they didn't fit the pattern established by
> the other DOM Recommendation APIs, and therefore weren't the best choice
> for an API that was supposed to fit in the larger scope of the web
> object model platform.  There's no _technical_ problem with calling it
> "xyz()".
Received on Thursday, 21 December 2006 00:56:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:22 UTC