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 () {
...
}.prototype.{
...
}
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
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
