Minimalist (why) classes ?

John J Barton johnjbarton at
Mon Nov 14 14:07:14 PST 2011

On Mon, Nov 14, 2011 at 11:51 AM, Brendan Eich <brendan at> wrote:
> 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.

Irakli proposes a function; you are discussing classes. So perhaps
rather than agreeing with Irakli you are drawing a parallel: you like
the object created by Irakli's extend() and wish to take that into the
"class" discussion?

That's all fine. But I am focusing on the function vs (class) syntax
issue. That is where Irakli's "(why) classes" comes from.

>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(...) {...}.

If we compare a |class| syntax
   class D extends B adds P;
to Irakli's extend, we write:
   var D = B.extend(P);
If both B and P can be expressions, then the forms are equivalent.
That is, both forms have to come up with an answer for how the B and P
are used in creating D.

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

Well he didn't suggest that, but it is a good idea ;-)  His extend()
could be built out of a 'merge' and a 'subclass', something like:

> You keep bringing in various extend alternatives, but these are separate from classes.

Yes, we agree here totally. But from my perspective I would say "You
keep bringing up classes, but these are separate from the
extend()-like functions".

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

I think some of my previous comments mixed up issues related to
[[Prototype]] and issues related to properties. There are some
similarities and, to further confuse us, much of the existing practice
in this area uses property copies to set [[Prototype]] links via
Foo.prototype/new Foo. I'll try to be better.

In the form
  class D extends B adds P;
   var D = B.extend(P);
the properties on P shadow the properties on B.  But the copy-ish
issue fall on B and P individually.

In Java/C++ languages B and P are highly constrained. Consequently the
copy-ish issue we discuss here don't apply.  If want B and P to be
arbitrary expressions, then we have to face how the properties of D
relate to the properties of B and P.

I guess Allen's form is:
  var D = B <| P;
where P is constrained to be a literal. I believe it still allows B to
have data values, which will be shared between instances of derived


More information about the es-discuss mailing list