Summary: prototypes as classes

Axel Rauschmayer axel at
Wed Jun 29 13:48:03 PDT 2011

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

Rephrasing my earlier response in reaction to your feedback:

I see it as a separation of concerns:
(1) Instantiation: Create a new instance, give it the proper prototype.
(2) Initialization: Set up the instance variables.

(1) Method "new"
(2) Method "initialize"

Prototypes-as-classes (starting from scratch, with a clean protocol that has no notion of constructor functions):
        new C(x,y)
desugars (conceptually!) to
        (new C).constructor(x,y)
(1) Instantiation: new C
(2) Initialization: .constructor(x, y)

I find that PaCs untangle (1) and (2), because method constructor() only has to play role (2), whereas constructor functions have to sometimes play both roles, sometimes only role (2) (when called from a sub-constructor).

Dr. Axel Rauschmayer

axel at


More information about the es-discuss mailing list