Minimalist (why) classes ?

Brendan Eich brendan at
Mon Nov 14 11:51:01 PST 2011

On Nov 14, 2011, at 8:48 AM, John J Barton wrote:

> On Sun, Nov 13, 2011 at 9:49 PM, Brendan Eich <brendan at> wrote:
>> On Nov 13, 2011, at 9:42 PM, Irakli Gozalishvili wrote:
>> I think this discussion drifted into slightly diff direction.
>> What I intended to say was that today all major frameworks use same patter
>> to do subclassing. They all implement different APIs to do the following:
>> function subclass() {
>>    // init ….
>> }
>> subclass.prototype = Object.create(superclass)
>> Object.defineProperty(subclass.prototype, 'constructor', { value: subclass
>> })
>> subclass.prototype.method = function() {
>>    //...
>> }
>> Yes, this is the heart of the matter. Not freezing, not shallow vs. deep
>> property copying (where deep must deal with closures at least).
> Sorry I don't understand.

I was agreeing with Irakli that subclass/superclass wiring is primal to classes. How one composes properties from various source objects is a different issue, not directly addressed by class syntax (yet). It is addressed by and you can use an expression in the superclass position in the class head: class D extends Trait.create(...) {...}.

> Every function which accepts object
> references and embeds its arguments in [[Prototype]] (either in the
> return value or the instance created from the return value)  faces the
> copy-ish problem.

Irakli was suggesting separating that from setting [[Prototype]] of a new subclass prototype object created at the same time, with constructor wired appropriately. That's what class syntax does at minimum.

You keep bringing in various extend alternatives, but these are separate from classes. Yes, even in the case when the class body is non-empty: in that event the elements define properties on the new class prototype object, which shadow any properties on the base class prototype object. Shadow, not copy.


More information about the es-discuss mailing list