es-discuss Digest, Vol 52, Issue 58

Brendan Eich brendan at
Tue Jun 14 23:35:10 PDT 2011

On Jun 14, 2011, at 11:25 PM, Axel Rauschmayer wrote:

> Cool! That’s what I meant when I wrote the following:
>> From: Axel Rauschmayer <axel at>
>> Date: June 13, 2011 10:55:56 GMT+02:00
>> To: Allen Wirfs-Brock <allen at>, es-discuss <es-discuss at>
>> Subject: Re: Classes: suggestions for improvement
>>> The correspondence is not quite that straight forward.  A prototype P, as used in self, does seem to frequently subsume the role of a class.  A constructor  generally corresponds to the copy method of such a prototype.
>> Isn’t that the illusion that class literals aim to create? That a class is actually a single construct, an object C with a method construct() and that you can apply the new operator to that object? new C(x,y) would perform the following steps:
>> - Create a new instance o whose prototype is C.
>> - Invoke o.construct(x,y)
>> Maybe "initialize" would be a better name than "construct", then.

Except we are still trying to sugar the prototypal pattern (but not name the constructor; rather, name the prototype). And the constructor property of the prototype is named 'constructor'.

Inventing a new protocol doesn't seem as good. We can't migrate constructor-function-with-.prototype property as directly; we have two protocols not one.

Yes, the "outer" object that's denoted by the "class name" is now the prototype, not the constructor. Even though we extend new and instanceof to avoid requiring '.constructor' suffixing, that dot and name may have to be manually suffixed otherwise -- to call super.constructor, to get at "class" methods and properties.

The loss of the manifest name for the abstraction denoting the constructor seems like the thing to discuss.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list