Closed
Description
Allow class to extend from generic type parameters (#4890)
Motivation: want to support mixin-like patterns
type Constructor = new (...args: any[]) => T;
class Base {
constructor(public x: number, public y: number) {}
}
class Derived extends Base {
constructor(x: number, y: number, public z: number) {
super(x, y);
}
}
function Tagged<T extends Constructor<Base>>(superClass: T) {
return class extends superClass {
_tag: string;
constructor(...args: any[]) {
super(...args);
this._tag = "hello";
this.x
}
}
}
-
Problems: substitutability is not guaranteed between the new type and a type parameter.
- Something that is not necessary to address now.
-
Right now this is modeled with intersections.
- When you intersect two types, TypeScript just recursively intersects members.
- Problem: but right now signatures of intersection types are just sequentially concatenated togehter.
- Example: the result of
T & U & V
has signatures ofT
followed by those ofU
followed by those ofV
.
- Example: the result of
- Idea: what if whenever we see a
(...args) => XXX
signature, take other signatures and intersect the return type.- Example
T
has a signature(x, y, z) => Derived
C
has type:(...args: any[]) => C
T & C
has type (x, y, z) => C & Derived
- Question: What if
...args: string[]
?- A: Restrict to
any[]
- A: Restrict to
- Question: Does order matter?
- A: Yes;
(...args: any[]) => XXX
only changes things if it's the latter type in the intersection.
- A: Yes;
- Question: Can the latter type have multiple overloads in the type for this to take effect?
- A: No.
- Question: Should these types by swapped around?
- Discussion
- Probably less code uses
(...args: any[]) => XXX
as first overload. - Methods and constructor in derived class should have overloads that come first - more accurately models signatures.
- Probably less code uses
- A: Yes, they should.
- Discussion
- Example
-
Issues: what about generic constructors?
- Can't model that well, but our thoughts are that we can eventually iterate.
-
Can we allow code that derives from
any
?- Conversation slips into call-site inference discussion.
Override keyword (#13217)
Current rules:
override
is only allowed on class property declarations.--noImplicitOverride
method.- Errors if you override a method without
override
. - Includes augmentations.
- Errors if you override a method without
- Should you be able to
override
static
members?- Unsure.
- What about
override abstract
methods?- Why?
- You want to substitute the signature, but acknowledge the
override
. - If so, why can't an interface have this?
- Let's say no for now.
- Resolution: let's take a look at the PR.
Expando object support
let x = {};
// add stuff to `x`
Another pattern:
var x = window.x || {}
Mainly for existing JavaScript patterns.
- Problem: "gazillion" different ways of achieving this.
Out of time.