Finding a "safety syntax" for classes

Brendan Eich brendan at mozilla.org
Fri Mar 23 13:17:05 PDT 2012


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


More information about the es-discuss mailing list