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

Re: ACTION-87: Selectors API

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 5 Jun 2006 22:40:34 -0700
Message-Id: <2D555610-560A-4C62-A0F0-E95B2C4B0EFF@apple.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
To: liorean <liorean@gmail.com>

On Jun 5, 2006, at 6:16 PM, liorean wrote:

>> On Mon, 05 Jun 2006 19:49:36 +1000, Anne van Kesteren  
>> <annevk@opera.com>
>> wrote:
>> > I'm not really fond of matchOne()... Is there any precedence on  
>> this?
> Not in JavaScript that I can think of. The only precedent case I can
> think of for this example is String.prototype.match.

For this reason I think "match" is a fine name for the single-result  
case. The default of regexp matching (likely the most familiar other  
match operation) is to give a single result. If there is to be  
another name it should be matchFirst though, not matchOne, to be  
clear that it's returning the first match not just some arbitrarily  
chose one.

>> I am with Jonas on this - I don't think the name hurts or increases
>> confusion and it does slightly decrease it. But picking names is  
>> always
>> painful. We'll never get it perfectly right, but we can always get it
>> oh-so-very wrong :(
> I tend to agree here. I don't like the suggested design of having
> selectors be second class though. I think selectors are important
> enough to have as first class objects, just like regex are.
> Compile them to an object once, use multiple times. Little is lost in
> performance for those using them once, but much is gained for those
> using them over and over.

1) This can be added later, if such use cases turn out to be important.

2) I think you are overestimating the available performance gains.  
Parsing the selector string is will likely be by far the least  
expensive part of the match operation.

Received on Tuesday, 6 June 2006 05:41:51 UTC

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