Re: Selectors API naming

On Dec 22, 2006, at 2:06 AM, Christophe Jolif wrote:

> You talk about common idioms, but all your example are about the  
> language, not about APIs. I think designing languages and API are  
> different matters. Indeed a language is the base of your  
> development, once chosen for a project, nobody will compete here  
> and you will have no conflict and also a very limited set of  
> keywords to remember. APIs are different, you have tons of them for  
> given language, and they must be as descriptive a possible to ease  
> their use. To sum up, I agree with you when it comes to languages,  
> I disagree for APIs and we are doing APIs not languages...

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:


// wouldn't want to mistake these for a point made in a debate!
CoordinateSystemPoint translate(CoordinateSystemPoint point, float  
horizontalDelta, float verticalDelta)
{
     point.horizontalCoordinate += horizontalDelta;
     point.verticalCoordinate += verticalDelta;
     return point;
}


Most graphics APIs instead do it more like this:

Point translate(Point point, float xDelta, float yDelta)
{
     point.x += xDelta;
     point.y += yDelta;
     return point;
}

I think most reasonable people would agree that this is better.  
Graphics code will probably spend a lot of time dealing with points  
(and rarely with other possible meanings for "x", "y" and "point").


It is somewhat debatable whether finding elements by selector would  
be as fundamental in the DOM as points are in graphics APIs, but I  
think there is at least some evidence to that effect.

Regards,
Maciej

Received on Saturday, 23 December 2006 05:56:50 UTC