Re: Selectors API naming

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