Sep 27 meeting notes

[Erik Arvidsson]

On Thu, Sep 29, 2011 at 16:54, Brendan Eich <brendan at mozilla.com> wrote:
> On Sep 30, 2011, at 12:22 AM, Erik Arvidsson wrote:
>
> 4. Allow const classes
>
> Hold this thought...
>
> 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.
>
> Obviously I like your thinking! Don't take my nit-picking below wrong.
> Please do pick or prove harmless-if-not-beneficial every nit.
>
> 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
> };
>
> Waldemar had some objections to comma elision in object literals, they would
> apply here too or need to be overcome. If we support only methods, then
> class body syntax can be its own thing, and drop otiose commas or other
> separators. But your prop:42 needs a , after it, Waldemar's counterexample
> used [privateName] as the next key and that would instead "index" into the
> previous property's value.
> So why do we need prototype data properties? I'd drop them as my (4), and
> keep const classes (since Mark will insist, and the desugaring is easy
> enough -- more below).
>
> 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.
>
> No need for "constructor: Derived // hand wave..." because <| clones (or
> unobservably mutates) its RHS function, and functions get .prototype
> properties with magic .constructor back-links for free. The mustache you use
> in the desugaring *extends* Derived.prototype, it does not lose the default
> .constructor back-link in that object.
> However, you do need a .constructor at the end, so the constructor and not
> its prototype is assigned to var Derived.
> Nit: s/var/let/ -- class should bind as let does, block-scoped and hoisted
> with temporal dead zone.
> Ok, here's the const class desugaring:
> const Derived =
>  Object.freeze(
>   Object.freeze(
>    Base <| function(x) {
>     this._x = x;
>     Object.seal(this);
>    }.prototype.{
>     get x() { ... },
>     prop: 42,
>     method() {}
>    }
>   ).constructor
>  );
> If you buy this, then I think class methods and other properties of the
> constructor are equally easy. We can defer them, but they do not add novel
> challenges as const instance variables and barriers to prevent partially
> initialized objects from leaking do. The only vexing issue is what syntax to
> use? A "static" keyword is at this point traditional, but we all hate it.
> Are we being too pure?
> /be

I would also be fine with a special class body.

I'm also fine with 'static'. Like everybody, I don't really like the
name but it is the best we have at the moment.

-- 
erik