Extending class 'extends' to work with expressions

[RyanCavanaugh]

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.

[fdecampredon]

what's the difference with #511 ? Does this issue is only for class expression ?

[danquirk]

Yeah gonna dupe this against #511 since that's the ES6 related work that must be done for this.