W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ACTION-87: Selectors API

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 22 Mar 2006 11:22:56 -0800
Message-Id: <731BCD0C-549B-4662-9493-BE240483EDB2@apple.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
To: Jim Ley <jim@jibbering.com>

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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC