Re: ACTION-87: Selectors API

"Anne van Kesteren" <annevk@opera.com>
> On Wed, 22 Mar 2006 14:43:29 +0100, Jim Ley <jim@jibbering.com> wrote:
>>> There is now:
>>>
>>>  .match()
>>>  .matchAll()
>>>
>>> ... per some discussion on #webapi. Thanks for your feedback.
>>
>> as per later discussion on #webapi, please change these names, .match is 
>> too similar to match in ES, and I would expect it to take a regular 
>> expression (perfectly reasonable to run a regular expression over a DOM).
>
> Fair enough, here are the requirements for the name:
>
> * short
> * simple

Why are these requirements for the name, no other DOM names are short and 
simple, they're clear and unambiguous, I'd say they were the requirements. 
If people want to use shorter names they understand in their closed world 
the $x() approach is perfectly simple for them (although discouraged by ECMA 
of course).

>> Also it's very odd to have .match() return only the first of something, 
>> it should return all of them, like everywhere else the name is used to 
>> avoid confusion (I'm not sure of the use case of just matching one 
>> anyway, please provide - if it's scripting performance, let's have a 
>> limit on the general case, because I often only what the first 4 things 
>> as much as only 1, gEBI covers the 1 case...)
>
> The reason is performance.

Then one 1 method with an optional limit is ,uch better, it optimises for 
all situations when the author knows how many they're interested in, rather 
than 1 special case.  I don't see why the 1 case is that much more special 
than the N case - as I say gEBI meets most of the 1 cases.

>> Mainly these names say nothing about their inescapable link to 
>> Selectors, they should.
>
> What would be the reason for that?

The understandability - if you're not going to link the names to the 
function, then .a() .b() etc. is the way to go, as it's very short, and very 
simple.

Jim.

Received on Wednesday, 22 March 2006 14:46:54 UTC