RE: Selectors API naming

On Mon, 18 Dec 2006, Chris Wilson wrote:
>
> If you'd like to suggest [using Chines], I can understand the 
> statistical reason.

I was just saying that if we want the majority of authors to understand 
the names, then using English is a non-starter. I'm not arguing that we 
shouldn't use English.


> Look, two choices - you should either try to make a system that hangs 
> together with the other specifications and is therefore somewhat 
> intuitive, or you should use the short possible names and presume the 
> user is going to look up the name every time.  I think the latter is 
> goofy. The former is a lesson learned, in my opinion, and applied to 
> the .Net framework - though there are tons and tons of people involved 
> in building .Net, by and large the APIs follow conventions in naming, 
> and that makes the APIs feel like they were designed together.

Sure... But we have to learn from the lessons we were taught by DOM and 
the way that authors are writing code. One of these lessons is that 
authors will hate typing long method names, to the point where they will 
alias one-letter names like $ to their most-used methods, making it 
completely pointless to have the name be obvious, and making reading the 
code far harder than even a short name would have.


> I'd rather a webdev not have to understand "oh, this API was done by the 
> DOM WG, so it uses this naming... this one was done by the WebAPI WG, so 
> it uses this other one..."

Well, the most obvious method name would be "document.select()". It's 
clear what it does given the context, and fits in well with the similar 
existing functionality, "document.all". Would "select()" be ok with you?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 19 December 2006 00:07:11 UTC