class sugar

Mark S. Miller erights at
Sat Jun 4 00:04:45 PDT 2011

On Fri, Jun 3, 2011 at 9:43 PM, Peter Michaux <petermichaux at>wrote:

> JavaScript has two well-known ways of doing object construction that
> could be argued to be class-like. (Trying to be careful with wording
> here.) There is the new/prototype/this-based system and there is the
> closure-based system.
> new/prototype/this-based system -----------------------
> function Point(x, y) {
>    this.x = x;
>    this.y = y;
> };
> Point.prototype.getDistance = function() {
>    return Math.sqrt(this.x * this.x + this.y * this.y);
> };

which can be expressed in classes as:

  class Point {
    constructor(x, y) {
      public x = x;
      public y = y;
    getDistance() {
      return Math.sqrt(this.x * this.x + this.y * this.y);

> closure-based system ----------------------------------
> function makePoint(x, y) {
>    return {
>        getDistance: function() {
>            return Math.sqrt(x * x + y * y);
>        }
>    };
> }

which can be expressed in classes as:

  class Point {
    constructor(x, y) {
      public getDistance() {
        return Math.sqrt(x * x + y * y);

> The classes strawman is proposing terse syntax to make the
> new/prototype/this-based system more aesthetic.
> Introducing class syntax will be one of the most monumental changes
> ever made to ECMAScript and I suggest that unfortunately the proposal
> is targeting the wrong version of creating constructors. I've found
> the closure-based system more compelling than the
> new/prototype/this-based system. My memory even makes me think that
> this list was heading in the direction of sugaring the closure-based
> system in 2008.
> Was using class syntax to sugar the closure-based system thrown out as
> a possibility for some reason?

Hi Peter, your memory is correct and the classes design has had a tortuous
history responding to many pressures. As you see from my rewrite of your two
examples above, the design we ended up promoting to harmony can express
both. While I agree that the objects-as-closure approach is more elegant, it
is less common. Most class-like code today is expressed in the
prototype/this-based style. As discussion continued among various committee
members, it became clear that a class proposal that served only the
objects-as-closures proposal could not achieve consensus. It also became
clear that we could adopt a proposal that served only the prototype/this
style. I'm glad to say that we did much better than that.

Some great virtue of the classes proposal that we adopted are that
* it can express the more common prototype/this-based style in a terse and
clear manner.
* code in the prototype/this-based style of classes can trivially be as
efficient as the corresponding common pattern is today, without arduous VM
* classes can interoperate in both directions with old conventional
prototype/this-based code
* objects-as-closures can still be expressed
* both patterns support string encapsulation
  a) prototype and instance methods can access "private(this)"-based
class-private instance variables.
  b) instance methods can access lexically captured instance-private
instance variables
* both patterns support high integrity in the context of a "const class".
* And perhaps most important, that it serves all these purposes with a very
simple design.

Personally, for new code that does not need to interoperate with old
prototype/this-based code and does not need to be super high performance, I
will always use the objects-as-closures pattern. For users like us, this
accepted class proposal has the following disadvantages:
* code in the objects-as-closure style is more verbose than it would have
been in earlier proposals, but not too bad.
* code in the objects-as-closure style is less likely to be efficient,
because the efficiency already supported by the other style removes the
pressure implement the optimizations needed to make the objects-as-closure
style efficient. (Of course, these optimizations are no less possible than
they were in the earlier proposals, it's just that they're less likely to

Altogether, given my weightings of these pros and cons, I am extremely happy
with these tradeoffs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list