Approach of new Object methods in ES5

Brendan Eich brendan at mozilla.com
Fri Apr 16 06:48:34 PDT 2010


On Apr 16, 2010, at 5:28 AM, Dean Edwards wrote:

> On 16 April 2010 13:13, Dmitry A. Soshnikov <dmitry.soshnikov at gmail.com 
> > wrote:
>
>> I think that approach used in ECMA-262-5 for new object methods  
>> contradicts ES nature.
>
> +1
>
> The new API seems quite random. I hope that JavaScript is not  
> turning into PHP.

Ouch! I've seen JS called a lot of things, but them's fighting words :- 
P.

Can you be more precise about "random"?

Is the problem the variation in naming convention (keys vs.  
getMySummerVacationWasLong), or prototype-based "instance" methods  
until ES5, constructor-based "static" methods in ES5?

The design is not random but it did involve a committee, which in  
particular accounts for some of the variation in style. This problem  
(for which I do not have a solution) affected ES3 too.

The static methods are to avoid "breaking the web" by injecting even  
non-enumerable names into every object -- including the global object  
-- via Object.prototype. Such injection can easily break user- 
controlled "object detection" done on colliding names.

It might take the sting out if there were a way to curry the leading | 
obj| parameter as |this| that was cheaper than

Object.defineProperty(Object.prototype, 'keys', {value: function ()  
{ return Object.keys(this); }});

In SpiderMonkey we have "uncurried" |this| from the Array extras and  
other prototype-based generic instance methods, to support  
Array.map(arraylike, ...) instead of  
Array.prototype.map.call(arraylike, ...). This was relatively easy to  
automate in our implementation. it's reminiscent of how Python class  
methods are reflected.

Perhaps something like this could be generalized to recover the  
preferred instance-based method from the "static" method, at the  
programmers discretion and with a concise opt-in expression of some  
sort.

/be


More information about the es-discuss mailing list