Finding a "safety syntax" for classes

Herby Vojčík herby at
Wed Mar 21 04:03:30 PDT 2012

Allen Wirfs-Brock wrote:
> We can live quite nicely with treating class declaration like const
> declarations. The name is logically hoisted so it is visible over the
> lexical scope, but the name is temporally dead until the class
> declaration is executed, in statement sequence, as an initializer. That
> means that we can have circular references between classes and forward
> references in inner functions to classes. The class declaration just
> need to be initialized before any such reference is actually evaluated.
> Its TDZ for classes.

+1 (I wrote similar thing)

> ...
> So here is my one possibly future hostile (or we need to decide now) issue:
> class A {};
> A.classProperty="A";
> class B extends A {};
> Console.log(B.classProperty); //"A" or undefined??
> I don't believe Russell said, one way or the other. Potentially either
He said "A" in answer to my post (where I assumed he means "A", I think 
it should be "A"):
>> [about Russell's proposal]: I silently assume here that extends
>> creates, of course, double chain (constuctor inherits as well as
>> prototype inherits, not just the latter)
> Correct

> way could be seen as future hostile if you think the "right" answer is
> the other one (and we have to do something in this regard). Personally I
> think the answer should be "A" which implies that we have class-side
> inheritance. This is a departure from current practice but because
> "classes are functions" there is no way in ES<=5.1 to set up class side
> inheritance other than by mutating __proto__.
> We could make an accommodation that this only occurs if the "superclass"
> object is a function. Otherwise, the "superclass" is only uses as the
> [[Prototype]] of the prototype and the constructor function simply
> inherits from Function prototype. BTW, I assume the thing the the right
> of extends is an expression.
> So, if you could say:
> class B extends A.prototype {}

Please, rather different syntax (or nothing) then different behaviour 
based on context.
After all, this is the less usual case, and can be achieved by:

let B = A.prototype <| function () {

> if you don't want the class-side inheritance
> To wrap up, this look really promising if we can restrict the feature
> scope in the manner Russell suggests. Hey, I could knock this off and
> have it in the spec. draft in a couple days work. There just isn't that
> much to it.
> Allen


More information about the es-discuss mailing list