Summary: prototypes as classes
brendan at mozilla.com
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  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