Re: Selectors API naming

On Sunday 24 December 2006 7:26 am, Martijn wrote:
> On 12/23/06, Maciej Stachowiak <mjs@apple.com> wrote:
> > I stand by my argument, which was about readability, not "ease of
> > use". I disagree that there is a fundamental distinction between
> > APIs and languages. Languages after all have a standard library,
> > which is an API. Consider a hypothetical graphics API:
>
> And a language is easier to learn when the standard library has been
> logically set up.

...which falls to the perspective and experience of the user, not 
necessarily just the "introduceability" of a new API. Languages like 
PHP and Python get quite a lot of mileage out of reusing common 
concepts, names, and idioms from their C dependency chain.

> document.matchAll is deviating from that.
> Document.getElementsBySelector has a higher readability in that
> regard I think.

I disagree. It's perhaps easier to *introduce*, but it's actually harder 
to read since it makes lines longer and therefore increases the need to 
wrap them. If you are looking to preserve the "this API handles 
selectors" semantic, one could propose document.bySelector(), but I 
think the argument that this or getElementsBySelector are better than 
match() or matchAll() are weak.

Your argument revolves around introducing this new function name to the 
global population of developers, and while I agree that it's a 
considerable cost, it will be a sunk cost much sooner than the effects 
of typing a longer name a billion times will be dissipated. Maciej's 
argument that this will be a critical API and therefore deserves a 
shorter name rings true with me in a way that optimizing for 
introduceability doesn't.

Regards

-- 
Alex Russell
alex@sitepen.com     A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723