atom feed72 messages in org.w3.public-webapiRe: ACTION-87: Selectors API
FromSent OnAttachments
5 earlier messages
Jim LeyFeb 25, 2006 11:47 am 
Ian HicksonFeb 25, 2006 3:56 pm 
Cameron McCormackFeb 25, 2006 4:46 pm 
Lachlan HuntFeb 25, 2006 4:58 pm 
Cameron McCormackFeb 25, 2006 5:01 pm 
Daniel SchierbeckFeb 25, 2006 5:25 pm 
Anne van KesterenFeb 26, 2006 2:21 am 
Cameron McCormackFeb 26, 2006 2:33 am 
Cameron McCormackFeb 26, 2006 1:04 pm 
Maciej StachowiakFeb 26, 2006 3:03 pm 
Jonas SickingFeb 28, 2006 1:57 pm 
Ian HicksonMar 6, 2006 12:33 pm 
Ian HicksonMar 6, 2006 12:35 pm 
Anne van KesterenMar 22, 2006 2:30 am 
Anne van KesterenMar 22, 2006 2:33 am 
Anne van KesterenMar 22, 2006 2:35 am 
mozerMar 22, 2006 3:16 am 
Anne van KesterenMar 22, 2006 3:58 am 
mozerMar 22, 2006 4:30 am 
Anne van KesterenMar 22, 2006 4:37 am 
Jim LeyMar 22, 2006 5:43 am 
Anne van KesterenMar 22, 2006 6:08 am 
Jim LeyMar 22, 2006 6:45 am 
Maciej StachowiakMar 22, 2006 11:16 am 
Maciej StachowiakMar 22, 2006 11:22 am 
Maciej StachowiakMar 22, 2006 11:25 am 
Robin BerjonMar 22, 2006 2:01 pm 
Maciej StachowiakMar 22, 2006 2:28 pm 
Ian HicksonMar 22, 2006 2:48 pm 
Ian HicksonMar 22, 2006 2:51 pm 
Maciej StachowiakMar 22, 2006 3:20 pm 
Jim LeyMar 22, 2006 6:17 pm 
Jim LeyMar 22, 2006 6:24 pm 
Anne van KesterenMar 23, 2006 4:28 am 
Ian HicksonMar 23, 2006 2:31 pm 
Anne van KesterenMar 25, 2006 4:36 am 
Ian HicksonMar 27, 2006 3:13 pm 
Anne van KesterenApr 3, 2006 5:46 am 
Anne van KesterenApr 3, 2006 5:51 am 
lioreanMay 12, 2006 8:49 pm 
Anne van KesterenMay 13, 2006 4:15 am 
lioreanMay 13, 2006 12:08 pm 
Anne van KesterenMay 13, 2006 12:26 pm 
lioreanMay 13, 2006 2:40 pm 
Anne van KesterenMay 14, 2006 7:20 am 
lioreanMay 14, 2006 4:22 pm 
Anne van KesterenMay 15, 2006 3:15 am 
lioreanMay 16, 2006 9:29 pm 
Anne van KesterenMay 17, 2006 5:18 am 
Lachlan HuntMay 17, 2006 6:19 am 
17 later messages
Subject:Re: ACTION-87: Selectors API
From:Maciej Stachowiak (mj@apple.com)
Date:Mar 22, 2006 11:22:56 am
List:org.w3.public-webapi

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

"Anne van Kesteren" <ann@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