Prototypes as the new class declaration

Brendan Eich brendan at mozilla.com
Sat Jun 18 13:36:21 PDT 2011


On Jun 18, 2011, at 12:51 PM, Juan Ignacio Dopazo wrote:

> I see the value in the <| operator in that it deals with any object. But I think the prototypes as classes idea is focusing on creating an object that describes a prototype and creating a constructor under the hood.

No, not under the hood -- explicitly via a constructor(){} method in the initialiser on the right of <|.


> This functionality can already be implemented in ES5 (see https://gist.github.com/1033258).

So for the most part can classes as proposed -- they are only sugar for the prototypal pattern, until you get into class-private instance variables, which are an open issue.

It is not enough to say "ES5 can do X". ES5 can do almost anything. We have good reason to add usable syntax for common patterns that entail too much boilerplate, therefore carry risk of errors in rewriting the boilerplace over and over, or production and download costs in acquiring it from a library.


>  It is pretty much what frameworks are doing today with different names for Function.create (new Class, Class.create, dojo.define, etc).

Yes, and that is true of classes as proposed, modulo private details. Indeed if you prefer the closure pattern for privacy and can stand the overhead, private can be done today. That does not mean classes or similar syntax (such as class-free super and <|) should not be added.


> However, isn't it the idea of classes to have a simple way of declaring instance, prototype and constructor properties (and make some of those private) in a single syntactic structure?

There's no single structure in classes as proposed if you read closely: constructor is (as in JS as used today) a prototype method with a separate body.

The public and private declarations within the constructor body for instance variables are novel and grammatically confined to that body, indeed, but there are two bodies: class and constructor. Thus "single" is not accurate.

The class methods and other "statics" are perhaps part of a "single [complex] syntactic structure" but they are not exactly singular -- they imitate declaration-with-initializer and method-in-object-literal forms but with some kind of prefix (BTW "static" is not the front-runner).

So classes have a number of parts, syntactically and semantically.

Allen's work on super and <|, plus the concise method syntax in object initialisers (adopted as part of classes), points toward another means to the same end. This approach has

  const WobblyPoint = Point <| {...}

instead of

  class WobblyPoint extends Point {...}

It has parity for new and instanceof usage via extensions to those operators that we've just been discussing.

Both classes and Allen's proposal have

  class Point { constructor(x, y) {...} ... }

Classes as proposed do have public and private declarations within the constructor body, with some big open issues for private.

I won't speak for Allen, but he, dherman and I have discussed the trade-offs of bundling such magic syntax into constructor body within class.

First, the instance variables seem a bit lost there. We put the declarations there for want of a better place.

Second, using declaration forms to define properties (in the case of public) looks like a mistake. This applies to prototype property bindings created by declarations nested directly in the class body (as ClassElements) too.

Third, private name objects are in ES.next and could be used (possibly with syntactic support for . instead of []) independently of classes and outside of so narrow a context as the constructor body.

Last, private open issues are making at least some of us wonder if we wouldn't have a better ES.next sooner by deferring the private part of classes as proposed.

This last point is no doubt contentious, but at least the third point means one can have private instance state that is efficiently allocated (as part of the one instance of a class). We would need to agree that Object.freeze does not freeze properties with private names.

Anyway, you can see what I am getting at: classes are not simple or unitary, they mix together separable features. We have accepted proposals for some of those features. Others as proposed as part of classes have open issues.

Therefore, it may pay to consider a class-free alternative that is about as syntactically convenient, but that is not such a hardcoded compound syntactic form, with some extra semantics for private and static that we still have to resolve.

Again I'm not trying to kill classes. They will emerge better and stronger, if they prevail, from doing this exercise, with as much attention to detail as we can stand.

Making classes into a "Scenario-solving" outcome where we hardcode unorthogonal forms and functions together would be a mistake. We've avoided that for the easy parts. I think we've done a bit of that for the harder parts (statics, privates), and it has left us with big open issues.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110618/eda85d51/attachment.html>


More information about the es-discuss mailing list