ES3.1 Object static methods rationale document

[Brendan Eich]

On Jul 18, 2008, at 9:02 AM, Allen Wirfs-Brock wrote:

> We ultimately concluded that the best way to think about what we  
> are currently provide is that it is a set of primitive mechanisms  
> that could be used to build higher level reflection facilities. If  
> we had a strong use case we could reintroduce getOwnProperties as  
> such a primitive, but so far it seem non-essential.  Incidentally,  
> when we removed getOwnProperties we had to add getOwnPropertyName  
> because otherwise you won't necessarily know what properties to ask  
> for using getOwnProperty

This trade-off comes up often with widely-targeted languages. JS is a  
case in point, but since it was over-minimized at the start,  
prematurely standarized, and then not evolved in the standard form  
for too long, the libraries have had to make up for the over- 
minimization, with inevitable gratuitous differences (minor, usually,  
in the case of functions like Object.extend).

Providing minimal, low-level facilities is not necessarily the best  
approach. If the audience demonstrably needs and already uses sugar,  
or a clichéd composite op, the language should give the people what  
they want. If the low-level primitive (call/cc) is too hard to use  
for most users, at least Lars and I have argued that simpler, easier- 
to-use, higher-level functionality (generators, based on Python --  
just one example) wins.

If Object.extend is the common case, but as Igor shows it can be  
built on (new name alert, and "own" only)  
Object.getPropertyDescriptors and defineProperties, it may be fine to  
provide only Object.extend and defer Object.getPropertyDescriptors.  
My own view is that at this point, given the proposed API, it's  
better to provide both. The low-level primitive for the uncommon  
cases not yet seen or thought of, and the higher-level API for the  
many libraries that roll their own equivalents.

/be