Re: ACTION-87: Selectors API

On Mar 22, 2006, at 6:45 AM, Jim Ley wrote:

>
> "Anne van Kesteren" <annevk@opera.com>
>> 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,

And that's why so much code is done with DOM Level 0 instead, or  
makes up functions with names like "$". To make an API that is fun  
and easy to use (and yes, I think this is a requirement for APIs on  
the web) it's important for common operations to have simple names.

>> 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.

It seems preferrable to have the single-item version be a shorter  
expression than the multi-match. I do think the 1 case is  
significantly different from the N case, because in the single-item  
case you won't loop, you will just want to do your processing directly.

>>> 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.

"match" strikes a good balance between brevity and clarity. It is  
common to speak of "matching a selector". Furthermore, the name  
"selectNodes" for a function that matches against an XPath expression  
seems accepted, even though it says nothing about XPath in the name.

Regards,
Maciej

Received on Wednesday, 22 March 2006 19:23:02 UTC