Sep 27 meeting notes

[Erik Arvidsson]

On Thu, Sep 29, 2011 at 10:22, Brendan Eich <brendan at mozilla.com> wrote:
> See dherman's minimal classes proposal, he minimized it slightly further on the whiteboard, kind of after the meeting / with only a few people looking.
>
> I still think minimal classes is smart if we're going to avoid too high an opportunity cost by working on bigger/alternative class designs.

I was going to send something out regarding the "even simpler classes"
proposal but I have a meeting with Alex and Bob Nystrom next week to
try to make progress on this and I wanted their feedback... however,
since the discussion is already taking place here it is.

Even Simpler Classes

There has been a lot of things discussed regarding classes. One thing
that I believe was agreed upon was to make classes syntactic sugar for
how people use prototype based inheritance today.

However, it seems like all the issues we have seen are due to us
trying to solve issues that already exist today with prototype based
"classes". These involve (but are not limited to):

1. Don't let uninitialized objects escape
2. Ensure the shape of the instance
3. Initialization of instance properties
4. Allow const classes
5. Allow const properties
6. Play well with future type guards

The question is do we have to solve these? I argue that we don't have
to solve these for ES.next. By postponing these we can provide an even
simpler class proposal that provides sugar to how people do
inheritance today using ES5.

class Derived extends Base { // Object literal body
  constructor(x) {  // constructor
    this._x = x;  // no special form
    // Disallow return expr?
  }  // optional comma from @awbjs
  get x() { return this._x; }
  prop: 42,
  method() {}  // method form @awbjs
};

This is syntactic sugar for

var Derived = Base <| function(x) {
  this._x = x;
}.prototype.{
  get x() { ... },
  prop: 42,
  method() {}
  constructor: Derived // hand wave here, needs {enumerable: false}
and reference to something not yet available.
}

This is pretty close to how both Ruby and Python classes behave and I
think we don't have to solve the problems raised above for ES.next.

-- 
erik