Typescript: 静的メンバーの多形「this」

私のボートのサイズと形は非常に似ています！ アホイ！

スーパークラスのファクトリメソッドは、そのサブクラスの新しいインスタンスを返します。 私のコードの機能は機能しますが、リターンタイプをキャストする必要があります：

class Parent {
    public static deserialize(data: Object): any { ... create new instance ... }
    // Can't return a this type from statics! ^^^ :(
}

class Child extends Parent { ... }

let data = { ... };
let aChild: Child = Child.deserialize(data);
//           ^^^ Requires a cast as type cannot be inferred.

今日もこの問題に遭遇しました！

修正ソリューションは、子型を基本クラスを拡張するジェネリックとして渡すことです。これは、当面は適用するソリューションです。

class Parent {
    static create<T extends Parent>(): T {
        let t = new this();

        return <T>t;
    }
}

class Child extends Parent {
    field: string;
}

let b = Child.create<Child>();

この問題が解決された理由はありますか？

私の意見では、これが静力学では機能しないという事実は、基本的にこの機能をDOAにします。 これまで、インスタンスメンバーでこれを実際に必要としたことはありませんでしたが、静的な処理のシステムは初期の頃に完成していたため、静的なものについては数週間ごとに必要でした。 この機能が発表されたときは大喜びでしたが、その後、インスタンスメンバーでのみ機能することに気付いたときに失望しました。

ユースケースは非常に基本的で非常に一般的です。 単純なファクトリメソッドを考えてみましょう。

class Animal
{
    static create(): this
    {
        return new this();
    }
}

class Bunny extends Animal
{
    hop()
    {
    }
}

Bunny.create().hop() // Type error!! Come on!!

この時点で、私は各継承者にstatic create()メソッドを醜いキャストまたはポイ捨てすることに頼っています。 この機能がないことは、言語のかなり大きな完全性の穴のように思えます。

@ paul-go問題は解決されていません...？

@ paul-go私もこの問題に不満を感じていますが、以下は私が見つけた最も信頼できる回避策です。 各Animalサブクラスは、super.create（）を呼び出して、結果をその型にキャストする必要があります。 大したことではなく、これを追加することで簡単に取り外せるワンライナーです。

コンパイラ、インテリセンス、そして最も重要なのはバニーがすべて幸せです。

class Animal {
    public static create<T extends Animal>(): T {
        let TClass = this.constructor.prototype;
        return <T>( new TClass() );
    }
}

class Bunny extends Animal {    
    public static create(): Bunny {
        return <Bunny>super.create();
    }

    public hop(): void {
        console.log(" Hoppp!! :) ");
    }
}

Bunny.create().hop();

         \\
          \\_ " See? I am now a happy Bunny! "
           (')   " Don't be so hostile! "
          / )=           " :P "
        o( )_

@RyanCavanaughおっと...どういうわけか私はこれを＃5862と混同しました...戦斧の攻撃性をお詫びします:-)

@ Think7うん...したがって、「各継承者の静的なcreate（）メソッドを醜いキャストまたはポイ捨てに頼る」。 ただし、ライブラリ開発者であり、エンドユーザーに、継承するクラスに型指定された静的メソッドの束を実装するように強制することはできません。

法律。 あなたのコードの下のすべてを完全に逃した：D

ああ、それだけの価値があった、バニーを描くようになった。

：+1：バニー

：rabbit ：： heart：

+1、間違いなくこれを見たい

このトピックに関するディスカッションの更新はありますか？

それは私たちの膨大な提案のバックログに残っています。

Javascriptはすでにそのようなパターンで正しく動作します。 TSも従うことができれば、多くの定型文/余分なコードから私たちを救うでしょう。 「モデルパターン」はかなり標準的なもので、JSがこれに対して行うようにTSが機能することを期待しています。

また、他の人と同じ「CRUDモデル」の理由から、この機能が本当に必要です。 インスタンスメソッドよりも静的メソッドで必要です。

これにより、＃8164で説明されている問題に対する適切な解決策が提供されます。

オーバーライドとジェネリックを使用した「ソリューション」があるのは良いことですが、ここでは実際には何も解決していません。この機能を使用する目的は、このようなオーバーライド/キャストを回避し、 thisが返される方法との一貫性を保つことです。タイプはインスタンスメソッドで処理されます。

私はSequelize4.0の型付けに取り組んでおり、 Modelクラスをサブクラス化するアプローチを使用しています。 そのModelクラスには、 findById()などの無数の静的メソッドがあります。もちろんModelは返しませんが、静的コンテキストではサブクラス、別名thisを返します。

abstract class Model {
    public static tableName: string;
    public static findById(id: number): this { // error: a this type is only available in a non-static member of a class or interface 
        const rows = db.query(`SELECT * FROM ${this.tableName} WHERE id = ?`, [id]);
        const instance = new this();
        for (const column of Object.keys(rows[0])) {
            instance[column] = rows[0][column];
        }
        return instance;        
    }
}

class User extends Model {
    public static tableName = 'users';
    public username: string;    
}

const user = User.findById(1); // user instanceof User

現在、これを入力することはできません。 SequelizeはNodeのORMであり、入力できないのは悲しいことです。 本当にこの機能が必要です。 唯一の方法は、これらの関数の1つを呼び出すたびにキャストするか、すべての関数をオーバーライドして、戻り値の型を調整し、 super.method()を呼び出す以外に何もしないことです。

また、静的メンバーはジェネリック型引数を参照できないことも関係しています。一部のメソッドは、型引数を介して型指定できるモデルの属性のオブジェクトリテラルを取りますが、インスタンスメンバーのみが使用できます。

😰これがまだ修正/追加されていないことを信じることができません.....

これをうまく利用することができます：

declare class NSObject {
    init(): this;
    static alloc(): this;
}

declare class UIButton extends NSObject {
}

let btn: UIButton = UIButton.alloc().init();

これが私が働きたいユースケースです（これを支持して閉じたhttps://github.com/Microsoft/TypeScript/issues/9775から移行しました）

現在、コンストラクターのパラメーターはthisタイプを使用できません。

class C<T> {
    constructor(
        public transformParam: (self: this) => T // not works
    ){
    }
    public transformMethod(self: this) : T { // works
        return undefined;
    }
}

予想：これはコンストラクターパラメーターで使用できます。

解決が求められている問題：

• 同じコードを再利用する別の流暢なAPIを中心に、流暢なAPIをベースにすることができます。

class TheirFluentApi {
    totallyUnrelated(): TheirFluentApi {
        return this;
    }
}

class MyFluentApi<FluentApi> {
    constructor(
        public toNextApi: (self: this) => FluentApi // let's imagine it works
    ){
    }
    one(): FluentApi {
        return this.toNextApi(this);
    }
    another(): FluentApi {
        return this.toNextApi(this);
    }
}

// self based fluent API;
const selfBased = new MyFluentApi(this => this);
selfBased.one().another();

// foreign based fluent API:
const foreignBased = new MyFluentApi(this => new TheirFluentApi());
foreignBased.one().totallyUnrelated();

将来を見据えた回避策：

class Foo {

    foo() { }

    static create<T extends Foo>(): Foo & T {
        return new this() as Foo & T;
    }
}

class Bar extends Foo {

    bar() {}
}

class Baz extends Bar {

    baz() {}
}

Baz.create<Baz>().foo()
Baz.create<Baz>().bar()
Baz.create<Baz>().baz()

このように、TypeScriptが静的メンバーに対してthisをサポートしている場合、新しいユーザーコードはBaz.create<Baz>() $ではなくBaz.create()になりますが、古いユーザーコードは問題なく機能します。 ：笑顔：

これは本当に必要です！ 特に、インスタンスを返す静的メソッドを持つDAOの場合。 それらのほとんどは、（保存、取得、更新など）のようにベースDAOで定義されています

静的メソッドのthis型が、クラスの型ではなく、それが含まれるクラスに解決されるため、混乱が生じる可能性があると言えます（つまり、 typeof ）。

実際のJSでは、型に対して静的メソッドを呼び出すと、関数内のthisがクラスであり、そのインスタンスではないため、一貫性がなくなります。

しかし、人々の直感では、静的メソッドでthisの戻り型を見るときに最初にポップアップするのは、インスタンス型だと思います...

@shlomiassafそれは矛盾しないでしょう。 Userなどの関数の戻り型としてクラスを指定すると、戻り型はユーザーのインスタンスになります。 まったく同じですが、静的メソッドでthisの戻り型を定義すると、戻り型はthisのインスタンス（クラスのインスタンス）になります。 クラス自体を返すメソッドは、typeofthisでモデル化できます。

@felixfbeckerこれは完全に視点のことです、これはあなたがそれを見る方法です。

JSで何が起こっているかを調べて、ロジックを推測できるようにします。

class Example {
  myFunc(): this {
    return this; 
  }

  static myFuncStatic(): this {
    return this;   // this === Example
  }
}

new Example().myFunc() //  instanceof Exapmle === true
Example.myFuncStatic() // === Example

さて、実際の実行時のthisは関数の制限されたコンテキストです。これは、インターフェイスのような流暢なAPIで発生することとまったく同じであり、この機能は、JSの動作と一致する適切な型を返すことで役立ちます。 thisを返す基本クラスは、派生クラスによって作成されたインスタンスを返します。 この機能は実際には修正されています。

総括する：
プロトタイプ（インスタンス）の一部として定義されているthisを返すメソッドは、インスタンスを返すことが期待されています。

そのロジックを続けると、クラス型（プロトタイプ）の一部として定義されているthisを返すメソッドは、クラス型である境界付きコンテキストを返すことが期待されます。

繰り返しますが、偏見、意見、単純な事実はありません。

直感的には、静的関数から返されるthisは、型内で定義されているため、インスタンスを表すのが快適ですが、それは私です。 他の人は違った考え方をするかもしれません、そして私達は彼らに彼らの間違ったことを言うことができません。

問題は、クラスインスタンスを返す静的メソッドとクラス自体を返す静的メソッド（このタイプ）の両方を入力できる必要があることです。 あなたのロジックはJSの観点からは理にかなっていますが、ここではreturn _types_について話し、TypeScriptやその他の言語でクラスをreturn type（ここではthis）として使用すると、常にクラスのインスタンスを意味します。 実際のクラスを返すために、typeof演算子があります。

@felixfbeckerこれは別の問題を引き起こします！

タイプthisがインスタンスタイプの場合、静的メソッドの本体でthisキーワードが参照しているものとは異なります。 return thisは、関数の戻り型typeof thisを生成しますが、これはまったく奇妙なことです。

いいえ、ちがいます。 次のようなメソッドを定義する場合

getUser(): User {
  ...
}

Userクラスではなく、User _instance_を取り戻すことを期待しています（これがtypeofの目的です）。 これは、すべての型指定された言語でどのように機能するかです。 タイプセマンティクスは、ランタイムセマンティクスとは単純に異なります。

thisまたはstaticキーワードを、子クラスで操作するためのfuncのコンストラクターとして使用してみませんか？

class Model {
  static find():this[] {
    return [new this("prop")]; // or new static(...)
  }
}

class Entity extends Model {
  constructor(public prop:string) {}
}

Entity.find().map(x => console.log(x.prop));

そして、これをJSの例と比較すると、正しく機能することがわかります。

class Model {
  static find() { 
    return [new this] 
  }
}

class Entity extends Model {
  constructor(prop) {
    this.prop = prop;
  }
}

Entity.find().map(x => console.log(x.prop))

静的メソッドでthisタイプを使用することはできません。これが、問題の根本的な原因だと思います。

@felixfbecker

このことを考慮：

class Greeter {
    static getHandle(): this {
        return this;
    }
}

この型アノテーションは直感的ですが、静的メソッドの型thisがクラスインスタンスである場合は正しくありません。 キーワードthisは、静的メソッドでtypeof thisのタイプを持っています！

thisは、クラスタイプではなく、インスタンスタイプを参照する必要があると思います。これは、インスタンスタイプ（ typeof X ）からクラスタイプへの参照を取得できるが、その逆はできないためです（ instancetypeof X ？）

@xealotわかりました、代わりに$ staticキーワードを使用してみませんか？ this ？ ただし、JS静的コンテキストのthisは、コンストラクターを指します。

@izatopはい、生成されたjavascriptは（適切または不適切に）機能します。 ただし、これはJavascriptに関するものではありません。 不満は、Javascript言語がこのパターンを許可していないということではなく、Typescriptの型システムが許可していないということです。

Typescriptは静的メンバーでポリモーフィックなthis型を許可しないため、このパターンでは型の安全性を維持できません。 これには、 staticキーワードとconstructorで定義されたクラスメソッドが含まれます。

遊び場リンク

@LPGhatguyですが、あなたは私の前のコメントを読みましたよね？！ 戻り型がUserのメソッドがある場合、 return User; return new User();を期待します。 同様に、戻り値this $は、静的メソッドのreturn new this();を意味します。 非静的メソッドではこれは異なりますが、 thisは常にオブジェクトであるため、インスタンス化することはできません。 しかし、最終的には、これがtypeofのために最良の構文であり、この機能がTSで非常に必要であることに基本的に同意します。

@xealot TypeScriptで多態的なthisが許可されていないことを理解しましたが、この機能をTSに追加しない理由をお聞きします。

この問題のすべてのユースケースで次のことが機能するかどうかはわかりませんが、静的メソッドでthis:型を使用し、型推論システムをスマートに使用すると、楽しみが得られることがわかりました。タイピング。 信じられないほど読みやすいとは言えないかもしれませんが、子クラスの静的メソッドを再定義しなくても機能します。

[email protected]で動作します

次のことを考慮してください。

// IModelClass is just here to describe an instanciator
// since we can't use typeof T (unfortunately) with
// the generic type system.
interface IModelClass<T extends Model> {
  new (...a: any[]): T

  // unfortunately, we have to put here again all the typing information
  // of the static members (without static, since we are describing a class, not an instance)

  some_member: string
  create<T extends Model>(this: IModelClass<T>): T
}

class Model {

  // Here we use this with the IModel<T> to force the
  // type system to use T as our current caller.

  static some_member: string

  // When we call Dog.create() below, T is thus resolved
  // to Dog *and stays that way*
  // If typeof worked on generic types (it doesn't), we could have defined this method
  // instead as 
  // static create<T extends Model>(this: typeof T): T { ... }
  static create<T extends Model>(this: IModelClass<T>): T {
    return new this() // whatever you fancy here
  }
}

class Dog extends Model {
  bark() { }
}

class Cat extends Model {
  meow() { }
}

// Everything should be typed here, and we didn't have to redefine static methods
// in Dog nor Cat
let dog = Dog.create()
dog.bark()
let cat = Cat.create()
cat.meow()

@ceymardなぜthisがパラメータとして指定されているのですか？

これは、 https：//github.com/Microsoft/TypeScript/issues/3694に付属しているtypescript 2.0.0が原因で、関数のthisパラメーターを定義できます（したがって、本体でthisを使用せずに使用できます）問題と機能の誤った使用を防ぐために）

静的メソッドだけでなくメソッドでも使用できることがわかりました。また、提供するthisを比較するように強制することで、型推論機能を「支援」するなど、非常に面白いものが可能になります。 （IModel）使用されているもの（犬、または猫）に。 次に、 Tの正しい型を「推測」して使用し、関数を正しく入力します。

（ thisはtypescriptコンパイラによって理解される_special_パラメータであり、関数にもう1つ追加されないことに注意してください）

構文は<this extends Whatever>のようなものだと思いました。 それで、 create()に他のパラメータがある場合でも、これは機能しますか？

絶対

また、これは組み込み型にとって重要であることも指摘したいと思います。
たとえば、 Arrayをサブクラス化すると、サブクラスのfrom()メソッドは、 Arrayではなく、サブクラスのインスタンスを返します。

class Task {}
class TaskList extends Array<Task> {
  public execute() {}
}
// actually returns instance of TaskList at runtime
const tasks = TaskList.from([new Task()])
tasks.execute() // error, method execute does not exist on type Array

この問題に関する更新はありますか？ この機能は、TypeScriptに関する私のチームの経験を大幅に強化します。

これはORMで一般的に使用されるパターンであり、多くのコードはコンパイラや型システムが想定するものとは大きく異なる動作をするため、これはかなり重要であることに注意してください。

私は反対の議論に対していくつかの反対の議論を提起するでしょう。

@shlomiassafが指摘したように、静的メンバーでthisを許可すると、 thisは静的メソッドとインスタンスメソッドで異なることを意味するため、混乱が生じます。 さらに、型アノテーションのthis thisのセマンティクスは異なります。 新しいキーワードを導入することでこの混乱を避けることができますが、新しいキーワードのコストは高くなります。

また、現在のTypeScriptには簡単な回避策があります。 @ceymardはすでにそれを示しています。 そして、静的メソッドの実行時セマンティクスをキャプチャするので、彼のアプローチを好みます。 このコードを検討してください。

class A {
  constructor() {}
  static create<T extends A>(this: {new (): T}) {} // constructor signature is exactly the same as A's
}

class B extends A {
  constructor(a: number) {
    super()
  }
}

B.create() // correctly trigger compile error here

多態性がサポートされている場合、コンパイラはclass B extends Aでエラーを報告する必要があります。 しかし、これは重大な変化です。

@HerringtonDarkholme混乱は見られません。戻り値のタイプは、 thisで、 return new this()に期待するものとまったく同じです。 そのためにselfを使用することもできますが、別のキーワード（出力の生成に使用されたもの以外）を導入する方が混乱しやすいようです。 すでにリターンタイプとして使用していますが、唯一の（しかし大きな）問題は静的メンバーではサポートされていないことです。

コンパイラーはプログラマーに回避策を要求するべきではありません。TypeScriptは「拡張JavaScript」であると想定されており、この場合は当てはまりません。コードが何百万ものエラーを生成しないように、複雑な回避策を実行する必要があります。 どういうわけか現在のバージョンでそれを達成できるのは素晴らしいことですが、それはそれが問題なく、修正を必要としないという意味ではありません。

では、なぜthisの戻り型がメソッド本体のthisの型と異なるのでしょうか。
このコードが失敗するのはなぜですか？ それを新参者にどのように説明できますか？

class A {
  static create(): this {
     return this
  }
}

JavaScriptのスーパーセットがこれを受け入れられないのはなぜですか？

class A {
  static create() {
    return new this()
  }
}

abstract class B extends A {}

確かに、別のキーワードを導入する必要があるかもしれません。 self 、またはinstanceの可能性があります

@HerringtonDarkholmeこれが私が新参者にそれを説明する方法です。
あなたがするとき

class A {
  static whatever(): B {
    return new B();
  }
}

Bの戻りタイプは、 Bのインスタンスを返す必要があることを意味します。 クラス自体を返したい場合は、次を使用する必要があります

class B {
 static whatever(): typeof B {
   return B;
 }
}

これで、JavaScriptの場合と同様に、静的メンバーのthisはクラスを参照します。 したがって、静的メソッドでthisの戻り型を使用する場合は、クラスのインスタンスを返す必要があります。

class A {
  static whatever(): this {
    return new this();
  }
}

クラス自体を返したい場合は、 typeof thisを使用する必要があります：

class A {
  static whatever(): typeof this {
    return this;
  }
}

これはまさに、TSでタイプがすでに機能している方法です。 クラスを使用して入力する場合、TSはインスタンスを予期します。 クラスタイプ自体を入力する場合は、 typeofを使用する必要があります。

次に、 thisがメソッド本体で同じ意味を持たない理由を尋ねます。 インスタンスメソッドの型アノテーションのthisが、対応するメソッド本体のthisと同じ意味を持つ場合、静的メソッドでは同じではないのはなぜですか？

私たちはジレンマに直面しており、3つの選択肢があります。

1. make thisは、さまざまなコンテキストでさまざまなことを意味します（混乱）
2. selfやstaticなどの新しいキーワードを導入する
3. プログラマーにもっと奇妙なタイプの注釈を書かせてください（一部のユーザーに影響を与えます）

3番目のアプローチは、静的メソッド定義の実行時セマンティクスを反映しているため、私は3番目のアプローチを好みます。
また、サイトを定義するのではなく、使用サイトのエラーを特定します。つまり、このコメントのように、エラーはclass B extends A B.createで報告されます。 この場合、使用サイトエラーはより正確です。 （ thisを参照する静的メソッドを宣言してから、抽象サブクラスを宣言することを検討してください）。

そして、最も重要なことは、新機能のための言語提案を必要としないことです。

確かに好みは人とは異なります。 しかし、少なくとも私はこのようなより詳細な提案を見たいと思っています。 抽象クラスの割り当て可能性、サブクラスの互換性のないコンストラクターシグネチャ、エラーレポート戦略など、解決すべき問題はたくさんあります。

@HerringtonDarkholmeインスタンスメソッドの場合、ランタイムthisはオブジェクトインスタンスであり、クラスではないため、混乱する余地はありません。 タイプthisが文字通りランタイムthisであることは明らかであり、他のオプションはありません。 静的な場合は、オブジェクト指向プログラミング言語の他のクラスアノテーションと同じように動作します。クラスでアノテーションを付けると、インスタンスが戻ってくることが期待されます。 さらに、TSの場合、JavaScriptクラスもオブジェクトであるため、クラスをtypeofと入力すると、リテラルクラスが返されます。

つまり、静的ケースについても考えるためにthisリターン型を実装し、代わりにユーザーにインスタンスメソッド用に常にtypeof thisを記述するように要求したときは、おそらくより一貫性があったでしょう。 しかし、その決定は当時行われたので、今すぐ作業する必要があります。私が言ったように、インスタンスメソッドのthisは他のタイプを生成しないため、混乱の余地はありません（クラスとは異なり、静的型とインスタンス型があります）ので、その場合は区別され、誰もが混乱することはありません。

OK、 thisで誰も混乱しないと仮定しましょう。 抽象クラスの割り当て可能性はどうですか？

メソッドの静的性はやや恣意的です。 すべての関数はプロパティとメソッドを持つことができます。 newでも呼び出すことができる場合は、これらのプロパティとメソッドをstaticと呼ぶことにします。 現在、この規則はECMAScriptにしっかりと組み込まれています。

@HerringtonDarkholme thisを使用すると混乱が生じることは間違いありません。 ただし、 thisの使用については何も間違いがないので、特にさまざまな代替案の鋭敏な費用便益分析を考慮すると、まったく問題ないと思います。 thisが最も悪い選択肢ではないと思います。

私は元の投稿からこのスレッドに追いつくことを試みました、多分これは少し軌道から外れたように感じます。

明確にするために、コンストラクターで、特にジェネリック/テンプレートとして使用される場合、 this型アノテーションが多形であることが望まれます。 @shlomiassafと@HerringtonDarkholmeに関しては、 staticメソッドを使用した例は混乱を招く可能性があり、この問題の意図ではないと思います。

そのように考えられることはあまりありませんが、クラスのコンストラクターは静的です。 この例（より明確なコメントで再投稿します）は、静的メソッドでthisを宣言していません。代わりに、静的メソッドの型アノテーションのジェネリックを介して将来使用するためにthisを宣言しています。 。

違いは、静的メソッドでthisをすぐに計算したくないのですが、将来的には動的メソッドで計算したいということです。

// START LIBRARY CODE
// Constrains the constructor to one that creates things that extend from BaseModel
interface ModelConstructor<T extends BaseModel> {
    new(fac: ModelAPI<T>): T;
}

class ModelAPI<T extends BaseModel> {
    // skipping the use of a ModelConstructor in favor of typeof does not work
    // constructor(private modelType: typeof T) {}
    constructor(private modelType: ModelConstructor<T>) {}

    create() {
        return new this.modelType(this);
    }
}

class BaseModel {
    // This is where "polymorphic `this`" in static members matters. We are 
    // trying to say that the ModelAPI should create instances of whatever 
    // the *current* class is, not the BaseModel class. Much like it would 
    // at runtime.
    constructor(private fac: ModelAPI<this>) {}

    reload() {
        // `reload()` returns a new instance of type Any, incorrect
        return this.fac.create();
    }
}
// END LIBRARY CODE

// START APPLICATION CODE
// Create a custom model class with custom behavior
class Model extends BaseModel {}

// Create an instance of the model API that produces my custom type
let api = new ModelAPI<Model>(Model);  // ModalAPI should be able to infer "<Model>" from the constructor?
let modelInst = api.create();  // Returns type of Model, correct
let reset = modelInst.reload();  // Returns type of Any, incorrect
// END APPLICATION CODE

これが紛らわしいと思う人には、まあ、それは非常に簡単ではないことに同意します。 ただし、 BaseModelのコンストラクターでのthisの使用は、実際には静的な使用ではなく、後で計算される延期された使用です。 ただし、静的メソッド（コンストラクターを含む）はそのようには動作しません。

実行時に、これはすべて期待どおりに機能すると思います。 ただし、型システムでは、この特定のパターンをモデル化することはできません。 typescriptがjavascriptパターンをモデル化できないことが、この問題が未解決である理由の根拠です。

これが紛らわしいコメントである場合は申し訳ありませんが、急いで書かれています。

@xealot私はあなたの主張を理解しましたが、静的メソッドの多形thisを具体的に示唆する他の問題は、これの複製としてクローズされました。 TSの修正により、両方のユースケースが有効になると思います。

あなたの正確なユースケースは何ですか？ たぶん、「この」ソリューションで十分です。

カスタムORMライブラリで使用して成功しました
ルジュ。 10月20日 2016à19：15、Tom [email protected] a
écrit：

これは一般的に使用されるため、かなり重要であることに注意してください
ORMのパターンと多くのコードは、
コンパイラと型システムはそうすべきだと考えています。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/5863#issuecomment -255169194、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAtAoRHc45B386xdNhuCLB8iW6i82e7Uks5q16GzgaJpZM4GsmOH
。

@ceymardと@HerringtonDarkholmeに感謝します。

static create<T extends A>(this: {new (): T}) { return new this(); }は私のためにトリックをしました👍

一見static create(): this { return new this(); }よりもわかりにくいですが、少なくとも正しいです！ 静的メソッド内のthisのタイプを正確にキャプチャします。

これが最も賛成またはコメントされていない場合でも、これが何らかの形で優先されることを願っています。たとえば、正しい型を取得するために型引数を使用する必要があるのは非常に面倒です。

let u = User.create<User>();

ただ行うことが実際に可能であるとき：

let u = User.create();

また、staticがインスタンスタイプを参照することは避けられません。

静的メンバーのthis型をクラスの静的側の型にするか、インスタンス側の型にするかについて、別の考えがありました。 thisは静的な側面である可能性があり、インスタンスメンバーで行われることと実行時の動作に一致し、 this.prototypeを介してインスタンスタイプを取得できます。

abstract class Model {
  static findAll(): Promise<this.prototype[]>
}

class User extends Model {}

const users: User[] = await User.findAll();

これは、JavaScriptでの動作と一致します。 thisはクラスオブジェクト自体であり、インスタンスはthis.prototypeにあります。 これは基本的にマップ型と同じメカニズムであり、 this['prototype']に相当します。

同様に、静的な側面がthis.constructorを介してインスタンスメンバーで利用可能であると想像できます（このATMのユースケースは考えられません）。

また、前述の回避策/ハックのいずれも、SequelizeでORMモデルを入力するために機能しないことにも言及したいと思います。

• this型アノテーションはコンストラクターでは使用できないため、このシグニチャーでは機能しません。
  ts abstract class Model { constructor(values: Partial<this.prototype>) }
• 静的メンバーはジェネリックパラメーターを参照できないため、ジェネリッククラス引数として型を渡すことは静的メソッドでは機能しません
• ジェネリックメソッド引数として型を渡すことは、メソッドに対しては機能しますが、次のような静的プロパティに対しては機能しません。
  ts abstract class Model { static attributes: { [K in keyof this.prototype]: { type: DataType, field: string, unique: boolean, primaryKey: boolean, autoIncrement: boolean } }; }

このリクエストには+1。 私のORMはとてもきれいになります。

すぐにクリーンなソリューションが表示されることを願っています

その間、解決策を提供してくれたすべての人に感謝します！

これ以上の議論がないので、これについてさらに進んでもいいですか？

どこに持っていきますか？ これは、私が知る限り、TypescriptがJavascriptをきれいにモデル化できず、単にそれを行わない以外の回避策を見たことがない方法です。

すでに3人の人気のあるORM所有者がこの機能を求めているのを見ることができるので、これはORM開発者にとって必須の機能です。

@ pleerock @ xealotソリューションは上記で提案されています。

export type StaticThis<T> = { new (): T };

export class Base {
    static create<T extends Base>(this: StaticThis<T>) {
        const that = new this();
        return that;
    }
    baseMethod() { }
}

export class Derived extends Base {
    derivedMethod() { }
}

// works
Base.create().baseMethod();
Derived.create().baseMethod();
// works too
Derived.create().derivedMethod();
// does not work (normal)
Base.create().derivedMethod();

私はこれを広く使っています。 基本クラスでの静的メソッドの宣言は少し重いですが、静的メソッド内のthisのタイプの歪みを避けるために支払う代償です。

@pleerock

this:パターンを問題なく広範囲に使用する社内ORMがあります。

確かに少し複雑ですが、機能が実際にすでにここにある場合は、言語を過充電する必要はないと思います。 より明確な構文のユースケースはかなり限定されたものであり、矛盾を引き起こす可能性があります。

たぶん、この質問と参照用のソリューションを備えたStackoverflowスレッドがある可能性がありますか？

@bjouhier @ceymardこのスレッドのすべての回避策がSequelizeで機能しない理由を説明しました： https ：//github.com/Microsoft/TypeScript/issues/5863#issuecomment -269463313

そして、これはORMだけでなく、標準ライブラリでもあります： https ：//github.com/Microsoft/TypeScript/issues/5863#issuecomment -244550725

@felixfbeckerコンストラクターのユースケースについて投稿し、それを削除しました（TSは、投稿直後にすべてのサブクラスでコンストラクターを義務付けているわけではないことに気付きました）。

@felixbeckerコンストラクターの場合については、パラメーターのないコンストラクターに固執し、代わりに特殊な静的メソッド（create、clone、...）を提供することで解決します。 より明確で入力が簡単です。

@bjouhierつまり、基本的にすべてのモデルサブクラスのすべてのメソッドを再宣言する必要があります。 Sequelizeにいくつあるか見てください：http： //docs.sequelizejs.com/class/lib/model.js~Model.html

私の議論は完全に異なる視点からです。 部分的でやや直感的でない回避策があり、それらが十分であるかどうかについて議論したり意見を異にしたりすることはできますが、これはTypescriptがJavascriptを簡単にモデル化できない領域であることに同意できます。

そして私の理解では、TypescriptはJavascriptの拡張である必要があります。

@felixfbecker

つまり、基本的にすべてのモデルサブクラスのすべてのメソッドを再宣言する必要があります。

どうして？ それは私の経験ではありません。 コードサンプルで問題を説明できますか？

@bjouhierこのスレッドのコメントのコードサンプルを使用して、問題を詳細に説明しました。https： //github.com/Microsoft/TypeScript/issues/5863#issuecomment -222348054

しかし、上記のcreateの例を見てください。 createメソッドは静的メソッドです。 再宣言されていませんが、サブクラスに適切に入力されています。 では、なぜModelのメソッドを再定義する必要があるのでしょうか。

@felixfbeckerあなたの_最初の_例：

export type StaticThis<T> = { new (): T };

abstract class Model {
    public static tableName: string;
    public static findById<T extends Model>(this: StaticThis<T>, id: number): T {
        const instance = new this();
        // details omitted
        return instance;        
    }
}

class User extends Model {
    public static tableName = 'users';
    public username: string;
}

const user = User.findById(1); 
console.log(user.username);

@bjouhierわかりました。つまり、 this: { new (): T }アノテーションによって、実際に型推論が機能するように見えます。 これは、なぜこれがコンパイラーが使用するデフォルトのタイプではないのか疑問に思います。
もちろん、コンストラクターはthisパラメーターを持つことができないため、回避策は機能しません。

はい、コンストラクターでは機能しませんが、静的なcreateメソッドを追加することで、APIを少し変更するだけで問題を回避できます。

私はそれを理解していますが、これはJavaScriptライブラリであるため、宣言に既存のAPIを入力することについて話します。

thisが静的メソッド内の{ new (): T } $を意味する場合、 thisは静的メソッド内のthisの正しいタイプではありません。 たとえば、 new this()は許可されません。 一貫性を保つために、 thisは、クラスインスタンスの型ではなく、コンストラクター関数の型である必要があります。

既存のライブラリの入力で問題が発生します。 そのライブラリを制御できない場合でも、適切に型指定されたcreate関数を使用して中間基本クラス（ BaseModel extends Model ）を作成し、 BaseModelからすべてのモデルを派生させることができます。

基本クラスの静的プロパティにアクセスする場合は、次を使用できます。

public static findById<T extends Model>(this: (new () => T) & typeof Model, id: number): T {...}

しかし、コンストラクターについてはおそらく有効なポイントがあります。 コンパイラが以下を拒否しなければならないという難しい理由はわかりません。

constructor(values: Partial<this>) {}

ここに痛みがあるという@xealotに同意します。 書けたらとてもかっこいいです

static findById(id: number): instanceof this { ... }

それ以外の

static findById<T extends Model>(this: (new () => T), id: number): T { ... }

しかし、タイピングシステムに新しい演算子が必要です（ instanceof ？）。 以下は無効です。

static findById(id: number): this { ... }

TS 2.4は、これらの回避策を打ち破りました。
https://travis-ci.org/types/sequelize/builds/247636686

@ sandersn @ felixfbeckerこれは有効なバグだと思います。 しかし、最小限の再現はできません。 コールバックパラメータは反変です。

// Hooks
User.afterFind((users: User[], options: FindOptions) => {
  console.log('found');
});

これはいつか修正される可能性がありますか？

今日もこれに出くわしました。 基本的に、次のようなシングルトン基本クラスを構築したかったのです。

abstract class Singleton<T> {
  private static _instance?: T

  public static function getInstance (): T {
    return this._instance || (this._instance = new T())
  }
}

使用法は次のようになります。

class Foo extends Singleton<Foo> {
  bar () {
    console.log('baz!')
  }
}

Foo.getInstance().bar() // baz!

私はこれの約10のバリエーションを試しましたが、上記のStaticThisのバリエーションと他の多くのバリエーションがあります。 結局、コンパイルすらできるバージョンは1つだけですが、 getInstance() Objectとして導出されました。

このように構成を操作する必要があるよりもはるかに難しいと感じています。

以下の作品：

class Singleton {
    private static _instance?: Singleton;

    static getInstance<T extends Singleton>(this: { new(): T }) {
      const constr = this as any as typeof Singleton; // hack
      return (constr._instance || (constr._instance = new this())) as T;
    }
  }

  class Foo extends Singleton {
    foo () { console.log('foo!'); }
  }

  class Bar extends Singleton {
    bar () { console.log('bar!');}
  }

  Foo.getInstance().foo();
  Bar.getInstance().bar();

this as any as typeof Singletonの部分は見苦しいですが、 _instanceを派生クラスのコンストラクターに格納する必要があるため、型システムをだましていることを示しています。

通常、基本クラスはフレームワークに埋め込まれるため、実装が少し醜い場合でもそれほど害はありません。 重要なのは、派生クラスのクリーンなコードです。

私は2.8ナイトリーで、次のようなことができることを望んでいました。

static findById(id: number): InstanceType<this> { ... }

悲しいことにそのような運はありません:(

@bjouhierコード例は魅力のように機能します。 ただし、IntelliSenseオートコンプリートを解除してください。

React 16.3.0がリリースされましたが、静的メソッドがクラス型パラメーターを参照できないため、新しいgetDerivedStateFromPropsメソッドを正しく入力することは不可能のようです。

（簡略化した例）

class Component<P, S> {

    static getDerivedStateFromProps?<K extends keyof S>(nextProps: P, prevState: S): Pick<S, K> | null

    props: P
    state: S
}

回避策はありますか？ （「PとSをPPとSSとして入力することは数えません。開発者が、これら2つの型族を正確に一致させることを願っています」：p）

PR： https ：//github.com/DefinitelyTyped/DefinitelyTyped/pull/24577

@cncolder私もインテリセンスの破壊を目撃しました。 私はそれがtypescript2.7から始まったと信じています。

ここに表示されていないことの1つは、シングルトンの例を拡張することです。シングルトン/マルチトンクラスに保護されたコンストラクターを持たせるのが一般的なパターンです。このように型が{ new(): T }の場合、これを拡張することはできません。パブリックコンストラクターを強制します-ここで提供されるthis用語または他のソリューション（ instanceof this 、 typeof thisなど）は、その問題を解決するはずです。 これは、シングルトンが作成などを要求しなかった場合にコンストラクターでエラーをスローすることで間違いなく可能ですが、それはエラーの入力の目的を無効にします-ランタイムソリューションを取得するために...

class Singleton {

  private static _instance?: Singleton;

  public static getInstance<T extends Singleton> ( this: { new(): T } ): T {
    const ctor: typeof Singleton = this as any; // hack
    return (ctor._instance || (ctor._instance = new this())) as T;
  }

  protected constructor ( ) { return; } 
}

class A extends Singleton {
  protected constructor ( ) {
    super();
  }
}

A.getInstance() // fails because constructor is not public

TSでgetInstance()のシングルトンが必要な理由はわかりません。オブジェクトリテラルを定義するだけです。 または、絶対にクラスを使用する場合（プライベートメンバーの場合）、クラスではなくクラスインスタンスのみをエクスポートするか、クラス式（ export new class ... ）を使用します。

これはマルチトンにとってより便利です-そして私はうまくいくパターンを見つけたと思います...それはこのタイプなしではまだ非常にハッキーな感じですが..代わりにこれは必要です

this -> { new(): T } & typeof Multiton | Function

class Multiton {
  private static _instances?: { [key: string]: any };

  public static getInstance<T extends Multiton> (
    this: { new(): T } & typeof Multiton | Function, key: string
  ): T {
    const instances: { [key: string]: T } =
      (this as typeof Multiton)._instances ||
     ((this as typeof Multiton)._instances = { });

    return (instances[key] ||
      (instances[key] = new (this as typeof Multiton)() as T)
    );
  }

  protected constructor ( ) { return; }
}

class A extends Multiton {
  public getA ( ): void { return; }
}
A.getInstance("some-key").getA();
assert(A.getInstance("some-key") === A.getInstance("some-key"))
new A(); // type error, protected constructor

キーを格納するコードもあるので、作成時に子クラスでアクセスできますが、簡単にするためにそれを削除しました...

こんにちは。 コンストラクターに多態的な「this」が必要な問題が発生しています。 このコメントに似ています。

クラスを作りたいです。 クラス自体には非常に多くのプロパティがあるため、そのクラスのすべてのプロパティがコンストラクターのパラメーターを介して初期化されている場合、コンストラクターは見栄えがよくありません。

私は、プロパティを初期化するためにオブジェクトを受け入れるコンストラクターを好みます。 例えば：

class Vehicle {
  // many properties here
  // ...

  constructor(value: Partial<Vehicle>) {
      Object.assign(this, value)
  }
}

let vehicle = new Vehicle({
  // <-- IntelliSense works here
})

次に、クラスを拡張したいと思います。 例えば：

class Car extends Vehicle {
  // more properties here
  // ...
}

let car = new Car({
  // <-- I can't infer Car's properties here
})

this型をコンストラクターでも使用できると非常に便利です。

class Vehicle {
  // ...
  constructor(value: Partial<this>) {
      // ...

したがって、IntelliSenseは、追加の定型文なしで子クラスのプロパティを推測できます。たとえば、コンストラクターを再定義します。 クラスを初期化するために静的メソッドを使用するよりも自然に見えます。

let car = new Car({
  // <-- Car's properties will be able to be inferred if Partial<this> is allowed
})

何卒よろしくお願い申し上げます。

このスレッドを見つけてよかったです。 正直なところ、これは非常に深刻な問題であり、3.0に移行するのを見るのは非常に落胆したと思います。

すべての解決策を検討し、過去2年間に試したさまざまな回避策を検討すると、解決策が整っている場合、私たちが試みる迅速な修正は単に失敗するという結論に達しました。 そしてそれまで、私たちが行うすべての強制は、プロジェクト全体でそれを維持するためにあまりにも多くの手作業を必要とします。 そして、一度公開されると、消費者にあなた自身の考え方を理解してもらい、彼らが単にあなたのパッケージをバニラで消費するが、私たちのほとんどのようにVSCodeで動作する場合、TypeScriptである何かを修正することを選んだ理由を理解するように求めることはできません。

同時に、実際の言語が問題ではないときに型システムを幸せにするコードを書くことは、そもそも型機能を使用するのとまったく同じ理由に反します。

みんなへの私の推薦は、波線が不完全であることを受け入れて、可能であれば//@ts-ignore because my code works as expectedを使うことです。

あなたのリンターが合理的な人間の知性の影響を受けない場合は、その場所を知っているリンターを見つける時が来ました。

更新：
静的推論を多分安全に拡張するための独自の試みを追加したかったのです。 このアプローチは、邪魔にならないように意図されているため、厳密にアンビエントです。 それは徹底的に明示的であり、継承があなたのために仕事をするだろうと単に仮定するのではなく、あなたにあなたの増強をチェックすることを強制します。

export class Sequence<T> {
  static from(...values) {
    // … returns Sequence<T>
  };
}

export class Peekable<T> extends Sequence<T> {
  // no augmentations needed in actual class body
}

/// AMBIENT /// Usually keep those at the bottom of my files

export declare namespace Peekable {
  export function from<T>(... values: T[]): Peekable<T>;
}

明らかに、このパターンが成り立つことや、このスレッドのすべてのシナリオを満たすことを保証することはできませんが、今のところ、期待どおりに機能します。

SafeArray

/**
 * Represents an Automation SAFEARRAY
 */
declare class SafeArray<T = any> {
    private constructor();
    private SafeArray_typekey: SafeArray<T>;
}

VarDate

/**
 * Automation date (VT_DATE)
 */
declare class VarDate {
    private constructor();
    private VarDate_typekey: VarDate;
}

今日はしばらく議論しました。 キーポイント：

• thisはインスタンス側または静的側を指しますか？
  
  
  
  • 間違いなく静的な側面。 インスタンス側はInstanceTypeOfを介して参照できますが、その逆は当てはまりません。 これにより、署名のthisが本文のthisと同じタイプになるという対称性も維持されます。
  
  
• 健全性の問題
  
  
  
  • 派生クラスのコンストラクターパラメーターリストがその基本クラスのコンストラクターパラメーターリストと何らかの関係があるという保証はありません。
  
  
  • クラスは、この点で静的側の代替可能性を非常に頻繁に破ります
  
  
  • 非構築側の代替可能性が強制され、これは通常、人々がとにかく興味を持っているものです
  
  
  • staticメソッドでのnew this()の不健全な呼び出しはすでに許可されています
  
  
  • 静的なthisの構成署名側を外部から気にする人はいないでしょうか。
  
  

既存の回避策：

class Foo {
    static boo<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();

特に、これはBarの構成署名がFooの代わりに適切に使用できる場合にのみ機能します。

@RyanCavanaugh私はthisの値があなたの例static boo<T extends typeof Foo>(this: T): InstanceType<T>から来ているという説明を考え出そうとしていましたが、私はそれを理解していません。 確かに私はジェネリック医薬品のすべてを読み直しましたが、それでも-いいえ。 たとえば、 thisをclazzに置き換えると、それは機能しなくなり、コンパイラは「1つの引数が必要ですが、0を取得しました」と文句を言います。 だから、いくつかの魔法がそこで起こっています。 説明してもらえますか？ または、ドキュメントの正しい方向を示してください。

編集：
また、なぜそれは単にextends Fooではなく$＃ extends typeof Foo $＃$なのですか？

@creynders thisは、関数のコンテキストに合わせて入力できる特別な偽のパラメーターです。 ドキュメント。

ジェネリックスが関係している場合、 InstanceType<T>の使用は機能しません。

私のユースケースは次のようになります。

const _data = Symbol('data');

class ModelBase<T> {
    [_data]: Readonly<T>;

    protected constructor(data: T) {
        this[_data] = Object.freeze(data);
    }


    static create<T, V extends typeof ModelBase>(this: V, data : T): InstanceType<V> {
        return new this(data);
    }
}

interface IUserData {
    id: number;
}

class User extends ModelBase<IUserData> {}

User.create({ id: 5 });

TypeScriptプレイグラウンドリンク

@mastermattああ、すごい、ドキュメントを読んでいるときに完全にそれを拾いませんでした...ありがとう

@RyanCavanaughの例を見ると、静的メソッドを機能させることができましたが、静的メソッドを参照するインスタンスメソッドもありますが、そのための正しい入力方法を理解できません。

例：

class Foo {
    static boo<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }

    boo<T extends typeof Foo>(this: InstanceType<T>): InstanceType<T> {
      return (this.constructor as T).boo();
    }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();
// c: Foo
let c = b.boo();

この最後の問題の回避策を見つけることができれば、何か公式なことが来るまで私は設定されます。

また、その例では、サブクラスが静的メソッドをオーバーライドしてsuperを呼び出そうとすると、すべてが混乱します...これら2つの問題を除けば、回避策は問題なく機能しているようです。 ただし、これら2つの問題は、コードをかなりブロックしています。

IIRCこれは、型システムを少し曲げないとタイプスクリプトで表現できないためです。 のように; this.constructorは、あなたが思っているもの、またはそのようなものであるとはまったく保証されていません。

その正確なケースでは、 boo()インスタンスメソッドがthisを返し、内部で少しチートして、コンパイラに自分が何をしているかを知っていることを受け入れさせます。

私の一般的な理由は、APIをコードの残りの部分でできるだけ単純にしたいということです。たとえ、それが少し不正行為を意味する場合でも。

誰かがもっと頑強なものを持っているなら、私はそれが大好きです

class Foo {
  static boo<T extends typeof Foo>(this: T): InstanceType<T> {
      return (new this()) as InstanceType<T>;
  }

  boo(): this {
    // @ts-ignore : wow this is ugly 
    return (this.constructor).boo();
  }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();
// c: Bar !
let c = b.boo();

インターフェイスルートに移動して、そのようなことを行うこともできます;

interface FooMaker<T> {
  new(...a: any[]): T
  boo(): T
}


class Foo {
  static boo<T extends typeof Foo>(this: T): InstanceType<T> {
      return (new this()) as InstanceType<T>;
  }

  boo(): this {
    return (this.constructor as FooMaker<this>).boo();
  }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();
// c: Bar !
let c = b.boo();

これも不正行為ですが、もう少し制御されているのではないでしょうか。 本当に言えません。

したがって、静的な「boo」メソッドの最初のthis引数は、通常の引数としてではなく、特別に扱われますか？ これを説明するドキュメントへのリンクはありますか？

class Foo {
    static boo<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();

私は同じ（少なくとも同様の）問題を抱えています。
私はJSDoc（TypeScriptではなく）でVanilla Javascriptを使用しているため、このスレッドで提案されているジェネリックを中心とした回避策を使用/実装することはできませんが、ルートは同じようです。
私はこの問題を開きました：＃28880

この問題は文字通りすでに3年になります。
誰かが私のために働くことができる適切な回避策を見つけましたか？

3年

@RyanCavanaughの回避策は静的メソッドには最適ですが、静的アクセサーはどうでしょうか。

class Factory<T> {
  get(): T { ... }
}

class Base {
  static factory<T extends Base>(this: Constructor<T>): Factory<T> {
    //
  }

  // what about a getter?
  static get factory<** no generics allowed for accessors **> ...
}

3年

さて、あなたは日付を引くのに半分まともです。 しかし、あなたは解決策を提供できますか？ ;）

@RyanCavanaughこれは、ジェネレーターで次のようにthis値を使用する場合の問題です。

class C {
  constructor(f: (this: this) => void) {
  }
}
new C(function* () {
  this;
  yield;
});

ジェネレーターを作成する場合、矢印関数を使用してthis値を使用することはできません。 したがって、サブクラスでthis型を明示的に宣言する必要があります。 実際のケースは次のとおりです。

      class Component extends Coroutine<void> implements El {
        constructor() {
          super(function* (this: Component) {
            while (true) {
              yield;
            }
          }, { size: Infinity });
        }
        private readonly dom = Shadow.section({
          style: HTML.style(`ul { width: 100px; }`),
          content: HTML.ul([
            HTML.li(`item`)
          ] as const),
        });
        public readonly element = this.dom.element;
        public get children() {
          return this.dom.children.content.children;
        }
        public set children(children) {
          this.dom.children.content.children = children;
        }
      }

https://github.com/falsandtru/typed-dom/blob/v0.0.134/test/integration/package.ts#L469

基本クラスで宣言できる場合は、サブクラスでthis型を宣言する必要はありません。 ただし、ジェネレータがスーパークラスで同期的に呼び出された場合、 this値は初期化されません。 私はコードでこの問題を回避しましたが、これは汚いハックです。 したがって、このパターンは元々、クラスベースのプログラミング言語と一致しない可能性があります。

最もクリーンではありませんが、静的メソッドから子クラスにアクセスするのに役立つ場合があります。

class Base {
    static foo<T extends typeof Base>() {
        let ctr = Object.create(this.prototype as InstanceType<T>).constructor;
        // ...
    }
}

class C extends Base {
}

C.foo();

私が現在直面している問題がこれによるものかどうかはわかりませんが、この問題を一目見ただけで、おそらくそうだと思われます。 そうでない場合は修正してください。

したがって、継承を介して関連する次の2つのクラスがあります。

export class Target {
  public static create<T extends Target = Target>(that: Partial<T>): T {
    const obj: T = Object.create(this.prototype);
    this.mapObject(obj, that);
    return obj;
  }
  public static mapObject<T extends Target = Target>(obj: T, that: Partial<T>) {
    // works with "strictNullChecks": false
    obj.prop1 = that.prop1;
    obj.prop2 = that.prop2;
  }

  public prop1!: string;
  constructor(public prop2: string) {}
}

export class SubTarget extends Target {
  public subProp!: string;
}

次に、次のようにSubTargetクラスにmapObjectメソッドを追加します。

  public static mapObject(obj: SubTarget, that: Partial<SubTarget>) {
    super.mapObject(obj, that);
    obj.subProp = that.subProp;
  }

これが機能することを期待していましたが、次のエラーが発生します。

Class static side 'typeof SubTarget' incorrectly extends base class static side 'typeof Target'.
  Types of property 'mapObject' are incompatible.
    Type '(obj: SubTarget, that: Partial<SubTarget>) => void' is not assignable to type '<T extends Target>(obj: T, that: Partial<T>) => void'.
      Types of parameters 'obj' and 'obj' are incompatible.
        Type 'T' is not assignable to type 'SubTarget'.
          Property 'subProp' is missing in type 'Target' but required in type 'SubTarget'.

この問題が原因でこのエラーが発生しましたか？ そうでなければ、説明は本当に素晴らしいでしょう。

遊び場へのリンク

呼び出された実際のクラスの新しいインスタンスを返す静的メソッドに注釈を付けるための解決策を探しているときにここに来ました。

@SMotaalによって提案された回避策（ new this()と組み合わせて）が最もクリーンで、私にとって最も理にかなっていると思います。 これにより、目的のインテントを表現でき、ジェネリックメソッドを呼び出すたびにタイプを指定する必要がなくなり、最終的なコードにオーバーヘッドが追加されることもありません。

しかし、真剣に、これはまだコアTypescriptの一部ではないのですか？ これはかなり一般的なシナリオです。

@danielvy — OOPとプロトタイプの間の断絶は、誰もが幸せになれない大きな精神的ギャップだと思います。 仕様でクラス機能が進化する前に作られたクラスに関する主要な仮定は一致していなかったと思います。それから抜け出すことは、多くの機能するTypeScript機能の落とし穴であるため、誰もが「優先」します。私の見解では「タイプ」。 競争よりも優れた解決策がないことは、競争がある場合にのみ問題になります。それが、1つのバスケットにあるすべての卵が常にすべての人にとって悪い理由です。私はここで実用的で誠実です。

これは機能しません：

export class Base {
  static getEntitySchema<T extends typeof Base>(
    this: T,
  ): InstanceType<T> {
  }
}

export class Extension extends Base {
  static member: string = '';
  static getEntitySchema<T extends typeof Extension>(
    this: T,
  ): InstanceType<T> {
  }
}

Type 'typeof Base' is missing the following properties from type 'typeof Extension ': member.

しかし、ExtensionはBaseを拡張するので、これは許可されるべきではありませんか？

これが機能することに注意してください。

export class Extension extends Base {
  static member: string = '';
  static getEntitySchema<T extends typeof Base>(
    this: T,
  ): InstanceType<T> {
  }
}

ただし、その中でthis.memberを使用することはできません。

したがって、 @ ntuckerの投稿から、拡張クラスが基本クラスと正確に一致しない限り、回避策は1レベルの深さでしか機能しないと推測していますか？

こんにちは！ 保護されたコンストラクターはどうですか？

class A {
  static create<T extends A>(
    this: {new(): T}
  ) {
    return new this();
  }

  protected constructor() {}
}

class B extends A {} 

B.create(); // Error ts(2684)

コンストラクターがパブリックの場合-問題ありませんが、そうでない場合はエラーが発生します。

The 'this' context of type 'typeof B' is not assignable to method's 'this' of type '(new () => B) & typeof A'.
  Type 'typeof B' is not assignable to type 'new () => B'.
    Cannot assign a 'protected' constructor type to a 'public' constructor type.

遊び場-http：//tiny.cc/r74c9y

これに希望はありますか？ もう一度この必要性に出くわしました：F

@ntucker Duuuuudee、やった!!! 私にとって重要な認識は、静的createメソッドをジェネリックにし、 thisパラメーターを宣言し、最後にInstanceType<U>キャストを実行することでした。

遊び場

上から^

class Base<T> {
  public static create<U extends typeof Base>(
    this: U
  ) {
    return new this() as InstanceType<U>
  }
}

class Derived extends Base<Derived> {}
const d: Derived = Derived.create() // works 😄 

これは私のユースケースを完全に満たし、TS 3.5.1の時点で、これはこのスレッドのpplの大部分も満たしているようです（静的プロップtheAnswerと第3レベルの拡張の探索については遊び場を参照してください）

ホットテイク：これは現在機能しており、閉じることができると思いますか？

@jonjaquesところで、Tを使用することはありません。また、これは、メソッドをオーバーライドするという、私が概説した問題を解決しません。

上記の解決策は、ほぼ4年前にすでに提案されているように感じますが、それでも問題を解決するものではありません。

私はスタックオーバーフローを開いて、誰かが知っているかもしれない他の回避策があり、誰かが私が経験している問題の良い要約を持っているかどうかを確認しました：

「このパラメーターを含め、メソッドパラメーターとして使用されるジェネリックスは反変のように見えますが、実際には、このパラメーターを常に共変（または多分二変）として扱う必要があります。」

したがって、これは実際にはTypeScript自体で壊れているものであり、修正する必要があるようです（「これ」は共変または二変である必要があります）。

編集：このコメントにはもっと良い方法があります。

追加するものはあまりありませんが、 https： //github.com/microsoft/TypeScript/issues/5863#issuecomment-437217433からうまくいきました。

class Foo {
    static create<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }
}

class Bar extends Foo { }

// typeof b is Bar.
const b = Bar.create()

これが、この長い問題を閲覧したくない人に役立つことを願っています。

別のユースケースは、非クラスのカスタム型ガードメンバー関数です。

type Baz = {
    type: "baz"
}
type Bar = {
     type: "bar"
}
type Foo = (Baz|Bar)&{
    isBar: () => this is Bar 
}

回避策は、私が必要な場所にほとんど到達しますが、ギアを投入するためのレンチがもう1つあります。 次の不自然な例を見てください。

interface IAutomobileOptions {
  make: string
}

interface ITruckOptions extends IAutomobileOptions {
  bedLength: number
}

export class Automobile<O extends IAutomobileOptions> {
  constructor(public options: O) {}

  static create<T extends typeof Automobile, O extends IAutomobileOptions>(
    this: T,
    options: O
  ): InstanceType<T> {
    return new this(options) as InstanceType<T>
  }
}

export class Truck<O extends ITruckOptions> extends Automobile<O> {
  constructor(truckOptions: O) {
    super(truckOptions)
  }
}

const car = Automobile.create({ make: 'Audi' })
const truck = Truck.create({ make: 'Ford', bedLength: 7 }) // TS Error on Truck

エラーは次のとおりです。

The 'this' context of type 'typeof Truck' is not assignable to method's 'this' of type 'typeof Automobile'.
  Types of parameters 'truckOptions' and 'options' are incompatible.
    Type 'O' is not assignable to type 'ITruckOptions'.
      Property 'bedLength' is missing in type 'IAutomobileOptions' but required in type 'ITruckOptions'.ts(2684)

Automobileクラスのcreateメソッドには$ ITruckOptionsからOまでの参照がないため、これは私には理にかなっていますが、その問題の回避策は？

通常、コンストラクターの拡張クラスのオプションは基本クラスのオプションインターフェイスを拡張するため、基本クラスのパラメーターが常に含まれることはわかっていますが、拡張のパラメーターが含まれていることを確認する信頼できる方法がありません。クラス。

また、クラスを拡張する際にメソッドをオーバーライドして、継承するクラスの予想される入力型と戻り型を通知する必要がありました。

@ Jack-Barryこれは機能します：

interface IAutomobileOptions {
  make: string
}

interface ITruckOptions extends IAutomobileOptions {
  bedLength: number
}

export class Automobile<O extends IAutomobileOptions> {
  constructor(public options: O) { }

  static create<T extends Automobile<O>, O extends IAutomobileOptions>(
    this: { new(options: O): T; },
    options: O
  ): T {
    return new this(options)
  }
}

export class Truck<O extends ITruckOptions> extends Automobile<O> {
  constructor(truckOptions: O) {
    super(truckOptions)
  }
}

const car = Automobile.create({ make: 'Audi' });
const truck = Truck.create({ make: 'Ford', bedLength: 7 });

ただし、コンストラクターは公開されているため、まだ理想的ではありません。そのため、 new Automobile({ make: "Audi" })を実行するだけで済みます。

@elderapoそれで私は必要なものを手に入れることができると思います-例はもちろん考案されていますが、_Generics_の理解の欠如が私を少し噛みしめたところがわかります。 片付けてくれてありがとう！

これが他の人の役に立つことを願っています。改善の余地があるかどうか教えてください。 読み取り関数がタイピングと同期しなくなる可能性があるため、完全ではありませんが、必要なパターンに最も近いものです。

// Interface to ensure attributes that exist on all descendants
interface IBaseClassAttributes {
  foo: string
}

// Type to provide inferred instance of class
type ThisClass<
  Attributes extends IBaseClassAttributes,
  InstanceType extends BaseClass<Attributes>
> = {
  new (attributes: Attributes): InstanceType
}

// Constructor uses generic A to assign attributes on instances
class BaseClass<A extends IBaseClassAttributes = IBaseClassAttributes> {
  constructor(public attributes: A) {}

  // this returns an instance of type ThisClass
  public static create<A extends IBaseClassAttributes, T extends BaseClass<A>>(
    this: ThisClass<A, T>,
    attributes: A
  ): T {
    // Perform db creation actions here
    return new this(attributes)
  }

  // Note that read function is a place where typechecking could fail you if db
  //   return value does not match
  public static read<A extends IBaseClassAttributes>(id: string): A | null {
    // Perform db retrieval here assign to variable
    const dbReturnValue = {} as A | null
    return dbReturnValue
  }
}

interface IExtendingClassAttributes extends IBaseClassAttributes {
  bar: number
}

// Extend the BaseClass with the extending attributes interface
class ExtendingClass extends BaseClass<IExtendingClassAttributes> {}

// BaseClass
const bc: BaseClass = BaseClass.create({ foo: '' })
const bca: IBaseClassAttributes = BaseClass.read('a') as IBaseClassAttributes
console.log(bc.attributes.foo)
console.log(bca.foo)

// ExtendingClass
// Note that the create and read methods do not have to be overriden,
//  but typechecking still works as expected here
const ec: ExtendingClass = ExtendingClass.create({ foo: 'bar', bar: 0 })
const eca: IExtendingClassAttributes = ExtendingClass.read(
  'a'
) as IExtendingClassAttributes
console.log(ec.attributes.foo)
console.log(ec.attributes.bar)
console.log(eca.foo)
console.log(eca.bar)

このパターンを残りのCRUDアクションに簡単に拡張できます。

@ Jack-Barryの例では、クラスのインスタンスを返すためにread関数を取得しようとしています。 私は以下が機能することを期待していました：

class BaseClass<A extends IBaseClassAttributes = IBaseClassAttributes> {

  public static read<A extends IBaseClassAttributes, T extends BaseClass<A>>(
    this: ThisClass<A, T>,
    id: string,
  ): T | null {
    // Perform db retrieval here assign to variable
    const dbReturnValue = {} as A | null
    if (dbReturnValue === null) {
      return null;
    }
    return this.create(dbReturnValue);
  }
}

しかし、代わりにエラーProperty 'create' does not exist on type 'ThisClass<A, T>'.を取得します。これに取り組む方法について誰かが回避策を持っていますか？

@everhardt createメソッドはstaticであるため、インスタンスではなく、 thisのclassで呼び出す必要があります。 とはいえ、 class関数に動的にアクセスして、目的の型チェックを提供する方法については、頭のてっぺんからうまく回避策がありません。

私が入手できる最も近いものは特にエレガントではなく、 BaseClass.create typeを使用できないため、簡単に同期が外れる可能性があります。

return (this.constructor as unknown as { create: (attributes: A) => T }).create(dbReturnValue)

私はこれを_テストしていません_。

@ Jack-Barryすると、 this.constructor.create is not a functionを取得します。

それは理にかなっています。Typescriptはthisをインスタンスとして解釈していますが、最終的なjavascriptパーサーの場合、関数は静的であるため、 thisがクラスです。

Jack-Barryの例の最もインスピレーションを得た拡張ではないかもしれませんが、このPlayground Linkで、私がどのように解決したかを確認できます。

核心：

• タイプThisClassは、BaseClassのメソッド（静的およびインスタンスの両方）がポリモーフィック 'this'で使用するすべての静的プロパティとメソッドを記述する必要があります。
• インスタンスメソッドで静的プロパティまたはメソッドを使用する場合は、 (this.constructor as ThisClass<A, this>)を使用します

クラスとThisClass型の両方で静的メソッドとプロパティの型を定義する必要があるため、これは二重の作業ですが、私にとっては機能します。

編集：遊び場のリンクを修正

PHPはずっと前にこの問題を修正しました。 自己。 静的。 これ。

みなさん、2020年です。_this_の問題があります。 😛

class Animal { 
  static create() { 
    return new this()
  }
}
class Bunny extends Animal {}
const bugs = Bunny.create() // const bugs: Animal

bugsがBunnyのインスタンスになると思います。

現在の回避策は何ですか？ 私はこの問題のすべてを試しましたが、何も修正されていないようです。

更新：これは機能しましたが、 this引数の定義がありませんでした。

class Animal { 
  static create<T extends typeof Animal>(this: T): InstanceType<T> { 
    return (new this()) as InstanceType<T>
  }
}
class Bunny extends Animal {}
const bugs = Bunny.create() // const bugs: Bunny

それに関する問題は、ゲッターとセッターが型パラメーターを持つことができないということです。

また、冗長すぎます。

私は同様の問題を扱っています。 「多態的な内部クラス」を実装するために、私が見つけることができる最良のものは次のとおりです。

class BaseClass {
  static InnerClass = class BaseInnerClass {};

  static createInnerClass<T extends typeof BaseClass>(this: T) {
    return new this.InnerClass() as InstanceType<T['InnerClass']>;
  }
}

class SubClass extends BaseClass {
  static InnerClass = class SubInnerClass extends BaseClass.InnerClass {};
}

const baseInnerClass = BaseClass.createInnerClass(); // => BaseInnerClass

const subInnerClass = SubClass.createInnerClass(); // => SubInnerClass

うまく機能しているように見えますが、 createInnerClass()の入力は私の意見では冗長すぎて、コードベースにたくさんあります。 このコードを単純化する方法について誰かが何かアイデアを持っていますか？

このアプローチの問題は、静的なゲッターとセッターでは機能しないことです。

静的プロパティにself.を実装するのはどうですか？ 私は4年前にこの問題を抱えていましたが、同じ問題で同じスレッドに戻ってきました。

@sudomaximeこれはこの問題の範囲外であり、 ECMAScriptがクラスのthis.constructor.のエイリアスとしてself.をネイティブにサポートしていない限り、 TypeScriptの設計目標に反して実行されます。 selfが一般的な変数名である場合に発生します。

@ abdullah-kasimのソリューションは説明どおりに機能するようですが、ジェネリッククラスで機能させることができません。

class Animal<A> {
  public thing?: A;

  static create<T extends typeof Animal>(this: T): InstanceType<T> {
    return new this() as InstanceType<T>;
  }
}

type Foo = {};
class Bunny extends Animal<Foo> {}

const bunny = Bunny.create(); // typeof bunny is Animal<unknown>
bunny.thing;                  // unknown :(

   __     __
  /_/|   |\_\  
   |U|___|U|
   |       |
   | ,   , |
  (  = Y =  )
   |   `  |
  /|       |\
  \| |   | |/
 (_|_|___|_|_)
   '"'   '"'

運が悪かったので少しいじってみたので、これが実現可能かどうかについて考えていただければ幸いです。

@stevehansonこれはあなたのために働きますか？

class Animal<A> {
  public thing?: A;

  static create<T>(this: new () => T): T {
    return new this() as T;
  }
}

type Foo = {asd: 123};
class Bunny extends Animal<Foo> {
    public hiya: string = "hi there"
}

const bunny = Bunny.create()


bunny.thing

const test = bunny.thing?.asd

const hiya = bunny.hiya

typescriptプレイグラウンドでこれをテストしました。

このリンクに触発されました：
https://selleo.com/til/posts/gll9bsvjcj-generic-with-class-as-argument-and-returning-instance

そして、Tがクラス自体であることをどのように暗示しているのかわかりません。 編集：ああ、覚えていましたが、サイレントthisパラメーターは常にクラス自体を渡すため、Tを暗示することができました。

@ abdullah-kasimこれはうまくいきました！ わぁ、ありがとう！ 私の特定のケースでは、コンストラクターが引数を取るので、他の誰かを助ける場合に備えて、これは私にとってはどのように見えたかでした：

  static define<C, T, F = any, I = any>(
    this: new (generator: GeneratorFn<T, F, I>) => C,
    generator: GeneratorFn<T, F, I>,
  ): C {
    return new this(generator);
  }

ここでの解決策のいくつかは、次の引数を渡すことができないため、静的ゲッターでは機能しません。

以下の例では、 default静的ゲッターを親クラスに移動するにはどうすればよいですか？

class Letters {
  alpha: string = 'alpha'
  beta?: string
  gamma?: string
  static get default () {
    return new this()
  }
}

const x = Letters.default.alpha;

構文の改善を検討する場合、これは検討する価値のあることかもしれません。

おそらく関連している：@ abdullah-kasimの例に別の抽象化レイヤーを追加するのに問題があります。 基本的に、 Animalをインターフェイスに変換し、 Bunnyが独自の静的create() $を定義できるようにしたいと思います。

これが実際的な例です（バニーのアナロジーを放棄することを許してください！）。 いくつかの異なるドキュメントタイプを定義できるようにしたいのですが、それぞれが文字列をドキュメントインスタンスに変換する静的ファクトリメソッドを定義できる必要があります。 ドキュメントタイプは、他のドキュメントタイプではなく、それ自体のパーサーのみを定義する必要があることを強制したいと思います。

（以下の例のタイプは完全には正しくありません。うまくいけば、私が達成しようとしていることは十分に明確です）

interface ParseableDoc {
    parse<T>(this: new () => T, serialized:string): T|null;
}

interface Doc {
    getMetadata():string;
}

// EXPECT: no error!
const MarkdownDoc:ParseableDoc = class implements Doc {
    constructor(private meta:string){ };
    getMetadata():string { return this.meta; };

    static parse(serialized:string):typeof MarkdownDoc | null {
        // do something specific
        return null;
    }
}

// EXPECT: type error, since class defines no static parse()
const MissingParseDoc:ParseableDoc = class implements Doc {
    constructor(private meta:string){ };
    getMetadata():string { return this.meta; };
}

// EXPECT: type error, since parse() should return a MismatchedDoc
const MismatchDoc: ParseableDoc = class implements Doc {
    constructor(private meta:string){ };
    getMetadata():string { return this.meta; };

    static parse(serialized:string):typeof MismatchDoc | null {
        // do something specific
        return null;
    }
}

（私は思う）私はこのようなものを書くことができるようになりたいです：

interface ParseableDoc {
    getMetadata():string;
    static parse<T extends ParseableDoc>(this: new () => T, serialized:string): T|null;
}

class MarkdownDoc implements ParseableDoc {
    getMetadata():string { return ""; }

    static parse(serialized:string):MarkdownDoc|null {
        // do something specific
        return null;
    }
}

ここでも回避策が可能かどうか考えてみてください。

編集：可能な回避策

StackOverflowの別のユースケース
汎用ルックアップテーブルクラスを設計するため。

// Generic part
abstract class Table<T extends Model> {
    instances: Map<number, T> = new Map();
}
abstract class Model {
    constructor(
        public readonly id: number,
        public table: Table<this>  // Error
    ) { 
        table.instances.set(id, this);
    }
}

// Example: a table of Person objects
class Person extends Model {
    constructor(
        id: number,
        table: Table<this>,  // Error
        public name: string
    ) {
        super(id, table);
    }
}
class PersonTable extends Table<Person> {}

const personTable = new PersonTable();
const person = new Person(0, personTable, 'John Doe');

// Note: the idea of using `this` as generic type argument is to guarantee
// that other models cannot be added to a table of persons, e.g. this would fail:
//     class SomeModel extends Model { prop = 0; }
//     const someModel = new SomeModel(1, person.table);
//                                        ^^^^^^^^^^^^

@ Think7は2016年5月29日にコメントしました
😰これがまだ修正/追加されていないことを信じることができません.....

ハハ
2020年はここにあります！

これはばかげて非常識です。 2020年です。4年後、なぜこれが修正されなかったのですか？

のようなものを実装してみませんか

class Model {
  static create(){
     return new static()
  }
  //or
  static create(): this {
     return new this()
  }
}

class User extends Model {
  //...
}

let user = new User.create() // type === User