Approach of new Object methods in ES5

Dmitry A. Soshnikov dmitry.soshnikov at
Sat Apr 17 02:03:21 PDT 2010

Hello Brendan,

Friday, April 16, 2010, 5:48:34 PM, you wrote:

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

>> On 16 April 2010 13:13, Dmitry A. Soshnikov <dmitry.soshnikov at 
>> > 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.

Without kidding -- that's similar to how PHP cannot manage how to name
their global functions -- e.g. with or without underscores.
And "Object.keys()" from some library which has no direct relation
with ES (previous) spec and implementations looks similar.

But yeah, of course it's not about PHP, so won't mention it anymore.

> Can you be more precise about "random"?

> Is the problem the variation in naming convention (keys vs.  
> getMySummerVacationWasLong),

Yes, it is. Is it not so essential? The question even not in that "I
should remember many things then" as Dean wrote (although, I see that
Dean's position is similar to mine) but in having different syntactic
(and what is more essential -- different ideological) approaches for
the same semantically entity -- using methods related with object.
That's about design, but not just about "I should remember more things".

> or prototype-based "instance" methods
> until ES5, constructor-based "static" methods in ES5?

Yes, of course. Does it sound like "it is not enought to talk about it"?

> 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.

Yes, I understand that this question should go directly to committee.

> 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.

That's the price (overloaded syntax with several ideolodies for the
same entity) for users of several combined libraries.

> 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); }});

Yeah, true.

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

Yes, but Python, having similar properties/methods
resolution, in contrast with ES has different approach (with passing
manual "self", and is just syntactic sugar for
There this is of course similar to, ...).

But in ES we have to make aliases in this case -- to improve the code
reuse and make it more elegant rather than write this long repeatable every time
"Objec.- Object.- Object.-" with forced indentions if we need to call
several operations.

Making aliases seems OK for me. In my local project in which I am sure and
understand all consequences of augmentation of built-ins (prototypes and
constructors, and therefore -- I can use language for full force) --
it will be the first thing I'll do -- provide convenient code reuse stylistics,
making aliases for all these new methods and place them into "Object.prototype"
with {enumerable: false}.

Regardless the meaning that to augment built-ins -- is a bad practice
-- this is the best approach of plugged in functionality from
the stylistics and code reuse viewpoint.

Of course I am talking only about own project where I'm free from
3rd-party libs naming collistions.

Providing so good mechanism (fully dynamic and mutable objects), you
call augmentations as bad practice. Of course it is -- if we deal with
environment we cannot trust (five 3rd-party libs are loaded + 10
scripts from untrusted sources). But if we're talking about own system
in which we can control anything and understand completely how this
system works -- it is very good approach.

But if you insist that it is a bad practice, it's easy to manage -- just
forbid then augmentations of built-ins completely that programmers
have no temptation to do this, like Python did. Yes, it turns on
backward compatibilities again. But at some step in future a radical decision
to stop support backward compat garbage and separate the new branch
can be made. That relates also for this new "use strict", which will
be supported all the time in the future for backward compats even if
nobody will use any deprecated things -- but all of them will continue
to pollute the course code with this "use strict".

But really, new plugged-in functionality looks more elegant in this




Technically, this isn't a big difference how to write it (except
algorithms of resolution):


or "foo".capitalize()

But ideologically the difference is.

And imagine this appear many times. The same with new approach of
Object.- Object.- Object.-. This is real example from
ExtJS lib. But yeah, this is the price for using combination of
3rd-party libs and of course I understand it. But unfortunately, this
became the price for the language syntax in a whole.

> 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.

Yes, I think so.

Anyway, Brendan, thanks a lot for your clarifications. It was useful to listen about
all these cases, including mutable __proto__ and new "private" "Name"s


More information about the es-discuss mailing list