On Thu, Sep 29, 2011 at 16:54, Brendan Eich <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
