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_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
