Summary: prototypes as classes

Brendan Eich brendan at
Tue Jun 28 18:38:55 PDT 2011

On Jun 28, 2011, at 6:33 PM, Axel Rauschmayer wrote:

> Sorry for dragging this out. The following should be my last email in this thread.

Axel, thanks for interacting, nothing to apologize for here.

>> The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a, b) with extra rules for object return value, which is a complexity. Especially for abstractions that want to be callable without 'new' to construct a new instance (Array, e.g.).
> That is complexity that is added to make things compatible with constructor functions and current built-ins. If you have to factor that in, then it is indeed hard to argue in favor of prototypes-as-classes.

There has to be a constructor function somewhere, somehow. The issue is what name you invoke it by when calling vs. constructing. With constructor-as-class it's the same name, the name of the abstraction denotes the constructor. With prototype-as-class, the two diverge -- you call C.constructor but you 'new C' (although you can spell out 'new C.constructor' too if you like).

> I don’t particularly like that most things are constructed via new, but that in a few cases, you can omit the “new” if you want to. I’m also trying to avoid the Array constructor (e.g. there is no way to create arrays such as [3] with it).

I hate that particular misfeature of Array.

> But I do understand that that’s how it is, that people use it and that there is nothing one can do about it.

The Array(length) botch aside, yes: many constructors are callable is functions and they construct in that case too.

> If I summarize my perceived advantages as follows, then it becomes clear that they might not be worth the trouble of having two kinds of classes:
> (1) Simpler instanceof (Contra: no need to look under the hood)
> (2) Simpler subclassing (Contra: not needed very often, super-references make most of the advantages go away). Minor inconvenience: having to set up C.prototype.constructor in the subclass.
> (3) Inheritance of class methods (Contra: I’ve only seen one case where this mattered – an inheritance API with an extend() method. Contra: property name pollution where constructors are currently used as namespaces).
> Looking at these points, it becomes clear that with class literals as syntactic sugar, we get all of the advantages of prototypes-as-classes, without their disadvantage of having to support two kinds of classes. However, class literals are still a move away from the constructor as the dominant construct (conceptually, – nothing changes under the hood).

It's true, classes want to slide down various lower slopes, over time. The "lint brush" problem, I called it. We on TC39 are obligated to hold the line.


More information about the es-discuss mailing list