-
Notifications
You must be signed in to change notification settings - Fork 13.2k
Description
Example
class B extends class C {
constructor() {
this.y = 4;
}
} {
constructor() {
this.x = 3;
}
}Codegen
Should be able to unpack the class expressions and codegen as we do now. We can pass the resulting expression as the parameter to the codegen’d constructor function as we do already.
Typecheck
The type of the expression follows the same rules we have for class declarations now. The expressions create constructor functions as before.
In the extends position, e.g. "class A extends B", the extends clause must be an expression, or a Generic NamedTypeReference. If it is an expression, the extends clause uses the type of the expression. This type must have a constructor signature.
This would allow it to be compatible with the current system and be more flexible with arbitrary expressions, as we would treat class name TypeReferences as constructor functions we will get the type of.
Questions
If C is visible outside of the scope, then we need to lift out and make visible. Else, we can just translate the expression and put it into the call to creating B’s constructor function
Traceur says it’s not in scope outside of B’s expression. Looks like we may be able to translate the expressions in-place as a call to the constructor function
If we base the typecheck on constructor signature, what about overloaded constructor signatures?
We require all overloads to return the same type
What about generic constructor signatures?
interface I { new<T>() T; }
We would disallow generic constructor signatures. These can’t arise as the type of a signature of a class’s constructor, so we’d follow a similar restriction.
What are the scoping rules of class B extends class C { /* can use T here? */ } { ... }
Needs answer
There is an ambiguity for parsing these as expressions (less than B, greater than, etc etc)
We would need to tweaking the parsing precedence to ensure the correct parse is checked first.