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()".
