On Apr 16, 2010, at 5:28 AM, Dean Edwards wrote:
On 16 April 2010 13:13, Dmitry A. Soshnikov <dmitry.soshni...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
