Allow class to extend from a generic type parameter

[wycats]

There appears to be some kind of internal "class" type that is impossible to represent generically:

You can see a live version here: http://goo.gl/exBzY6

function IdentifiableSubclass<T extends What?>(SuperClass: T) {
 return class extends T {
 public _id = null;
 }
} 

class Thing {
 public hello = null;
 /* impl */
}

const IdentifiableThing = IdentifiableSubclass(Thing);

class ChildThing extends IdentifiableThing {

}

let child = new ChildThing();
child.hello; // TS does not understand that this exists
child._id; // TS understands that this exists

[DanielRosenwasser]

Hey Yehuda Katz (@wycats), I assume you meant return class extends SuperClass { /* ... */ }.

Yeah, I tried something like:

interface Constructable<T> {
 new (...args): T;
 prototype: T
}

function IdentifiableSubclass<T>(SuperClass: Constructable<T>) {
 return class extends SuperClass {
 public _id = null;
 }
} 

with no luck since, like you mentioned, the constructed type needs to be resolved to a class or an interface. I think the limitation should be from extending primitive types, not from non-class/interface types. Anders Hejlsberg (@ahejlsberg) can you weigh in on this?

[DanielRosenwasser]

Actually, this comes back to not being able to know if a type parameter is a primitive or not. I think this comes back to #1809.

[ahejlsberg]

Yehuda Katz (@wycats) Here's something that works:

interface Constructor<T> {
 new (...args): T;
}

interface Base {
}

interface Identifiable {
 _id: any;
}

function IdentifiableSubclass<T extends Base>(SuperClass: Constructor<T>) {
 class C extends (<Constructor<Base>>SuperClass) {
 public _id = null;
 }
 return <Constructor<Identifiable & T>>C;
}

class Thing {
 public hello = null;
 /* impl */
}

const ChildThing = IdentifiableSubclass(Thing);
let child = new ChildThing();

child.hello; // Ok
child._id; // Ok

Some comments on what's going on...

First, we have a hard constraint that you can only inherit from a class or interface type, and not from type parameter (similar to Java, C#, and pretty much any mainstream OOP language). A key reason is that we can't properly check whether the base class has properties that conflict with the derived class when we don't yet know the final shape of the base class. This also highlights the primary differences between extends and the & operator: The & operator allows the type operands to be type parameters but doesn't cause errors when properties have the same name. Instead, & recursively applies & to the types of the similarly named properties.

So, in the IdentifiableSubclass method, I'm "casting away" the type parameter (such that C effectively extends the statically known Base) and then "casting back" to the intersection type Identifiable & T. This means that child ends up having the type Identifiable & Thing.

The fact that you can only inherit from a class or interface type also (unfortunately) implies that you can't inherit from an intersection type. Therefore, you can't do the last bit of your example where you inherit ChildThing from IdentifiableThing.

I'm definitely open to suggestions on making things more flexible here, but we're pushing close to the limits of our type system (and, really, any other type system I know of).

[tejacques]

Is there an inherent reason why classes can't inherit from an intersection type? It seems like the entire shape is known in that scenario, so maybe support could be added? It would have to reconcile that intersection types could have different type declarations on the same properties, but on the surface still seems like it could be done (and disallow those with an error).

Another possibility that affords a much friendlier looking implementation would be to lift the typing up to the call site where the shape is known, and check the constraints there (much like templating in C++ as much as that thought probably horrifies everyone). At the declaration function you'd only be able to check the base type, but you could get an error at the callsite when you were doing something improper:

interface Base<T> {
 new(): T
}

function IdentifiableSubclass<T>(SuperClass: Base<T>) {
 // Only compatibility with Base<T> can be checked here
 return class C extends SuperClass {
 constructor(id) {
 super()
 }
 public _id: number = 0;
 };
}

class Thing {
 public hello = null;
 /* impl */
}

const ChildThing = IdentifiableSubclass(Thing);

// Error: Supplied parameters do not match any signature of call target.
let child = new ChildThing();

child = new ChildThing(/* id = */ 1234); // Ok

child.hello; // Ok
child._id; // Ok

class BadThing {
 public _id: string;
 // constructor(name: string) {}
}

// Could produce Error: Anonymous class 'C' incorrectly extends
// base class 'BadThing'. Types of property '_id' are incompatible.
// Type 'number' is not assignable to type 'string'
const BadChildThing = IdentifiableSubclass(BadThing);

That might be a longshot as a proposal for this issue, but this class of generic type propagation and errors/type checking at the callsite could in general help tremendously.

As an alternative to using a Base/Constructor interface, it might also be possible to use <T extends typeof BaseClass>, like so:

class BaseClass {
}

function IdentifiableSubclass<T extends typeof BaseClass>(SuperClass: T) {
 // Only compatibility with BaseClass can be checked here
 return class C extends SuperClass {
 constructor(id) {
 super()
 }
 public _id: number = 0;
 };
}

The <T extends typeof BaseClass> notation already accepts classes of the right typing, but cannot be used as a constructor function type, for presumably the same reason that the shape is unknown.

Anyway, that could be nice, but I'm guessing would likely be a side-effect of a much larger different proposal for callsite propagation type checking. Would still love to hear any thoughts on it though.

[mhegazy]

The proposal we discussed for this issue before is to introduce a new extends type operation, that is similar to intersection, but only picks the first member in case the two types had members with the same name, in addition the new operation will ignore errors to allow extending from type parameters.

[tejacques]

Interesting. So the proposal is something like this?

interface A {
 A: number
 B: number
}

interface B {
 A: string
 B: number
 C: boolean
}

type AorB = A | B;
let aORb: AorB;
aORb.A // number | string
aORb.B // number
aORb.C // error -- can only access under typeguard on B

type AandB = A & B;
let aANDb: AandB;
aANDb.A // number & string
aANDb.B // number
aANDb.C // boolean

type AenhancedB = A || B;
let aENb: AenhancedB;
aENb.A // number
aENb.B // number
aENb.C // boolean

I used || here since it fits decently well with JavaScript semantics: a || b is a, or b if a doesn't have a value. How would it resolve more complicated types? Does it merge them recursively?

[mhegazy]

that is correct. except that i would call it a extends b. and no there is no recursive merging. at least this is the proposal.