Finding a "safety syntax" for classes

Russell Leggett russell.leggett at gmail.com
Fri Mar 23 13:34:46 PDT 2012


On Fri, Mar 23, 2012 at 4:17 PM, Brendan Eich <brendan at mozilla.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120323/dae9fb9d/attachment.html>


More information about the es-discuss mailing list