Re: Selectors API naming

Hi-

I agree.  I think "getElementsBySelector()" is a good name that follows 
a meaningful naming convention.

Having a slightly longer name for a method doesn't prevent people from 
making shorter aliases, but having an unclear name does prevent people 
from understanding it intuitively.

Regards-
-Doug



Kelly wrote:
> 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 01:22:17 UTC