You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To better support subclassing built-ins, and still support built-ins and pre-ES6 "classes" that can also be called as functions, we should be able to merge the call signatures of ambient function declarations with the static side of a class declaration.
Current state
Currently, if you want to declare an ambient "class" that has both call and construct signatures, you need to use an interface-interface-var pattern, as follows:
// instance-side interface typeinterfaceArray<T>{/*...*/}// static-side interface typeinterfaceArrayConstructor{<T>(length: number): T[];new<T>(length: number): T[];/* ... */}// value declaration for constructordeclarevarArray: ArrayConstructor;
This is a problem, however as "classes" defined using this pattern cannot be used in the extends clause of a class declaration in TypeScript.
Proposal
Merge ambient function and class declarations with the same name. Ambient function declarations with the same name as an ambient class declaration in the same lexical scope would contribute their call signatures to the static side of the class declaration. For example:
Summary
To better support subclassing built-ins, and still support built-ins and pre-ES6 "classes" that can also be called as functions, we should be able to merge the call signatures of ambient function declarations with the static side of a class declaration.
Current state
Currently, if you want to declare an ambient "class" that has both call and construct signatures, you need to use an
interface
-interface
-var
pattern, as follows:This is a problem, however as "classes" defined using this pattern cannot be used in the
extends
clause of a class declaration in TypeScript.Proposal
Merge ambient function and class declarations with the same name. Ambient function declarations with the same name as an ambient class declaration in the same lexical scope would contribute their call signatures to the static side of the class declaration. For example:
Out of scope
The text was updated successfully, but these errors were encountered: