On Fri, Mar 23, 2012 at 4:17 PM, Brendan Eich <[email protected]> wrote:
> 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.
Ah, makes more sense now. I think there's a lot of room for future work.
The current behavior that I think we're agreeing on seems very intuitive
with the way JS works now. Future behavior should have more signposts like
the "const" keyword would for const i.v.s.
- Russ
>
>
> /be
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
