Finding a "safety syntax" for classes

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

On Fri, Mar 23, 2012 at 4:17 PM, Brendan Eich <brendan at> 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: <>

More information about the es-discuss mailing list