Russell Leggett wrote:
Yeah, that's one of the things that confused me. Brendan specified
instance properties, which made me think he was referring to an error
that might occur prior to actually evaluating the code.
Yes, the issue is not the class binding (if the class was declared,
rather than expressed). The issue is instance variables. I'm going back
to the old syntax from last year that we don't like any longer, which
declared i.v.s in the constructor body:
class Point extends Evil {
constructor(ax, ay) {
public x, y;
super();
this.x = ax;
this.y = ay;
}
...
}
The issue is what happens if class Evil looks like this:
class Evil {
constructor() {
console.log(this.x);
}
}
Should undefined by logged, or an error thrown? If the i.v.s are made
const, or guarded by guard expressions, does the answer change? Can we
do non-const i.v.s now and let undefined be read, and be future-friendly?
I think we can -- it seems obvious to me.
But I may be missing something (since we haven't got const i.v.s or
guards in Harmony yet, who knows? This is the unfalsifiable limit where
we can't do classes until we do other more advanced and uncertain things).
Also it may be that some on TC39 think the answer to "Should undefined
be logged?" for the example above is "no, error thrown". I don't agree
with that, it's not how writable properties on objects work in JS.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
