静的インターフェースメソッドは一般的に意味がありません。＃13462を参照してください。

それについてのフィードバックがさらに聞こえるまで、これを保留します。

これを検討するときに私たちが持っていた主な質問：誰がabstract staticメソッドを呼び出すことができますか？ おそらく、 AbstractParentClass.getSomeClassDependentValueを直接呼び出すことはできません。 しかし、タイプAbstractParentClassの式でメソッドを呼び出すことはできますか？ もしそうなら、なぜそれが許可されるべきですか？ そうでない場合、この機能の用途は何ですか？

静的インターフェースメソッドは一般的に意味がありません。＃13462を参照してください。

＃13462の説明では、 staticインターフェイスメソッドが無意味である理由がわかりませんでした。 私はそれらの機能が他の手段で実装できることだけを見ました（それはそれらが無意味ではないことを証明します）。

実用的な観点からは、インターフェースは一種の仕様であり、このインターフェースを実装するクラスでの実装に必須の特定のメソッドのセットです。 インターフェイスは、オブジェクトが提供する機能を定義するだけでなく、一種のコントラクトでもあります。

したがって、 classにstaticメソッドがあるのに、 interfaceにはないという論理的な理由はわかりません。

言語ですでに実装できるものはすべて構文やその他の改善を必要としないという観点に従うと（つまり、この議論は＃13462の議論の主要なポイントの1つでした）、これによって導かれます観点から、 whileサイクルは、 forとifを一緒に使用して実装できるため、冗長であると判断できます。 ただし、 whileを廃止するつもりはありません。

これを検討するときに私たちが持っていた主な質問：誰がabstract staticメソッドを呼び出すことができますか？ おそらく、 AbstractParentClass.getSomeClassDependentValueを直接呼び出すことはできません。 しかし、タイプAbstractParentClassの式でメソッドを呼び出すことはできますか？ もしそうなら、なぜそれが許可されるべきですか？ そうでない場合、この機能の用途は何ですか？

良い質問。 この問題を検討していたので、これについてのアイデアを教えてください。

コンパイラレベルでは、 AbstractParentClass.getSomeClassDependentValueの直接呼び出しの場合は追跡されず（追跡できないため）、JSランタイムエラーが発生することに気付くだけです。 しかし、これがTypeScriptのイデオロギーと一致しているかどうかはわかりません。

私はそれらの機能が他の手段で実装できることだけを見ました（それはそれらが無意味ではないことを証明します）。

何かが実装可能であるという理由だけで、それが理にかなっているという意味ではありません。 😉

abstract class Serializable {  
    abstract serialize (): Object;  
    abstract static deserialize (Object): Serializable;  
}  

Serializableのサブクラスに静的deserializeメソッドを強制的に実装したいと思います。
そのような動作を実装するための回避策はありますか？

これに関する最新の見解は何ですか？ 抽象クラスの抽象静的プロパティを書き込もうとしたところ、許可されていないことに本当に驚いていました。

@ patryk-zielinski93が言ったこと。 私たちがTSに変換するPHPの数年のプロジェクトから来て、私たちはインターフェースに静的メソッドが必要です。

これが役立つ非常に一般的なユースケースは、Reactコンポーネントです。これは、 displayName 、 propTypes 、 defaultPropsなどの静的プロパティを持つクラスです。

この制限のため、Reactの型指定には、現在2つの型が含まれています。 Componentクラスと、コンストラクター関数と静的プロパティを含むComponentClassインターフェイスです。

すべての静的プロパティを備えたReactコンポーネントを完全に型チェックするには、両方の型を2つ使用する必要があります。

ComponentClassのない例：静的プロパティは無視されます

import React, { Component, ComponentClass } from 'react';

type Props = { name: string };

{
  class ReactComponent extends Component<Props, any> {
    // expected error, but got none: displayName should be a string
    static displayName = 1
    // expected error, but got none: defaultProps.name should be a string
    static defaultProps = { name: 1 }
  };
}

ComponentClassの例：静的プロパティは型チェックされます

{
  // error: displayName should be a string
  // error: defaultProps.name should be a string
  const ReactComponent: ComponentClass<Props> = class extends Component<Props, any> {
    static displayName = 1
    static defaultProps = { name: 1 }
  };
}

静的プロパティが型チェックされていないことに気づいていないのに、現在多くの人がComponentClassを使用していないのではないかと思います。

関連する問題： https ：//github.com/DefinitelyTyped/DefinitelyTyped/issues/16967

これについて何か進展はありますか？ または、抽象クラスのコンストラクターの回避策はありますか？
次に例を示します。

abstract class Model {
    abstract static fromString(value: string): Model
}

class Animal extends Model {
    constructor(public name: string, public weight: number) {}

    static fromString(value: string): Animal {
        return new Animal(...JSON.parse(value))
    }
}

@roboslone

class Animal {
    static fromString(value: string): Animal {
        return new Animal();
    }
}

function useModel<T>(model: { fromString(value: string): T }): T {
    return model.fromString("");
}

useModel(Animal); // Works!

これは非常に強力で便利な機能であることに同意しました。 私の見解では、この機能がクラスを「第一級市民」にしているのです。 クラス/静的メソッドの継承は、特に他のポスターによって何度かここで呼び出されている静的メソッドのファクトリパターンの場合、意味があります。 このパターンは、TypeScriptで頻繁に実行される操作である逆シリアル化に特に役立ちます。 たとえば、すべての実装タイプがJSONからインスタンス化可能であることを示すコントラクトを提供するインターフェースを定義することは完全に理にかなっています。

抽象静的ファクトリメソッドを許可しない場合、実装者は代わりに抽象ファクトリクラスを作成する必要があり、クラス定義の数が不必要に2倍になります。 そして、他のポスターが指摘しているように、これはPHPやPythonなどの他の言語で実装された強力で成功した機能です。

Typescriptは初めてですが、これがデフォルトで許可されていないこと、そして非常に多くの人々が次のいずれかで機能を追加しないことを正当化しようとしていることにも驚いています。

1. TSはこの機能を必要としません。なぜなら、他の手段でやろうとしていることをまだ達成できるからです（これは、私が見た、非常に客観的に優れた方法の例を提供する場合にのみ有効な議論です。ごくわずか）
2. できないからといって、そうすべきだという意味ではありません。 すばらしい：しかし、人々はそれがどのように有用/有益であるかについての具体的な例を投稿しています。 それを許可することがどのように傷つくかわかりません。

別の簡単な使用例:(理想的な方法、これは機能しません）

import {map} from 'lodash';

export abstract class BaseListModel {
  abstract static get instance_type();

  items: any[];

  constructor(items?: any[]) {
    this.items = map(items, (item) => { return new this.constructor.instance_type(item) });
  }

  get length() { return this.items.length; }
}

export class QuestionList extends BaseListModel {
  static get instance_type() { return Question }
}

代わりに、リストインスタンスは、インスタンスタイプを直接公開することになります。これは、リストインスタンス自体には関係がないため、コンストラクターを介してアクセスする必要があります。 汚れた感じ。 同じ種類のメカニズムなどを介してデフォルト値のセットを指定するレコードモデルについて話していると、はるかに汚い感じになります。

長い間ruby / javascriptを使用した後、ある言語で実際の抽象クラスを使用することに本当に興奮しましたが、実装の制限にがっかりしました-上記の例は、これに遭遇した最初の例にすぎませんでしたが、多くのことを考えることができますそれが役立つ他のユースケース。 主に、静的インターフェイスの一部として単純なDSL /構成を作成する手段として、クラスがデフォルト値オブジェクトまたはそれが何であれを指定することを保証します。 -そして、あなたは考えているかもしれません、まあそれがインターフェースの目的です。 しかし、このような単純なものの場合、それは実際には意味がなく、必要以上に複雑になるだけです（サブクラスは抽象クラスを拡張し、いくつかのインターフェイスを実装する必要があり、名前付けがより複雑になります、等）。

私のプロジェクトには、これと同様の要件が2回ありました。 それらは両方とも、すべてのサブクラスが一連の静的メソッドの具体的な実装を提供することを保証することに関連していました。 私のシナリオは以下のとおりです。

class Action {
  constructor(public type='') {}
}

class AddAppleAction extends Action {
  static create(apple: Apple) {
    return new this(apple);
  }
  constructor(public apple: Apple) {
    super('add/apple');
  }
}

class AddPearAction extends Action {
  static create(pear: Pear) {
    return new this(pear);
  }

  constructor(public pear: Pear) {
    super('add/pear');
  }
}

const ActionCreators = {
  addApple: AddAppleAction
  addPear: AddPearAction
};

const getActionCreators = <T extends Action>(map: { [key: string]: T }) => {
  return Object.entries(map).reduce((creators, [key, ActionClass]) => ({
    ...creators,
    // To have this function run properly,
    // I need to guarantee that each ActionClass (subclass of Action) has a static create method defined.
    // This is where I want to use abstract class or interface to enforce this logic.
    // I have some work around to achieve this by using interface and class decorator, but it feels tricky and buggy. A native support for abstract class method would be really helpful here.
    [key]: ActionClass.create.bind(ActionClass)
  }), {});
};

これが私の要件を説明できることを願っています。 ありがとう。

回避策を探している人は、次のデコレータを使用できます。

class myClass {
    public classProp: string;
}

interface myConstructor {
    new(): myClass;

    public readonly staticProp: string;
}

function StaticImplements <T>() {
    return (constructor: T) => { };
}

<strong i="7">@StaticImplements</strong> <myConstructor>()
class myClass implements myClass {}

const getActionCreators = <T extends Action>(map: { [key: string]: {new () => T, create() : T}}) => {

型パラメーターを介して呼び出しているため、仮想のabstract staticファクトリメソッドを持つ実際の基本クラスが関与することはありません。 タイプパラメータがインスタンス化されると、サブクラスのタイプは構造的に関連付けられます。

この説明で私が見ていないのは、いくつかの合成型ではなく、基本クラスの型を介して実装が呼び出される場合です。

abstractメンバーが派生クラスの実装によって実際に_オーバーライド_されるC＃などの言語とは異なり、JavaScriptメンバーの実装は、インスタンスなどでは、継承された数値をオーバーライドすることはなく、むしろそれらを_シャドウ_することを考慮することも重要です。

ここでの私の5セントは、ユーザーの観点からは次のとおりです。

インターフェイスの場合、 _static_修飾子を許可する必要があります

インターフェイスは、クラスを実装することによって実行されるコントラクトを定義します。 これは、インターフェースがクラスよりも高いレベルの抽象化であることを意味します。

今私が見ることができるのは、クラスに静的メソッドを持つことができるという方法で、クラスはインターフェースよりも表現力がありますが、コントラクト定義自体からそれを強制することはできません。

私の意見では、それは間違っていて邪魔だと感じています。

この言語機能の実装を困難または不可能にする技術的背景はありますか？

乾杯

インターフェイスは、クラスを実装することによって実行されるコントラクトを定義します。 これは、インターフェースがクラスよりも高いレベルの抽象化であることを意味します。

クラスには2つのインターフェースと2つの実装コントラクトがあり、それから逃れることはできません。
C＃のような言語にもインターフェイスへの静的メンバーがないのには理由があります。 論理的には、インターフェースはオブジェクトのパブリックサーフェスです。 インターフェイスは、オブジェクトのパブリックサーフェスを記述します。 つまり、そこにないものは何も含まれていません。 クラスのインスタンスでは、静的メソッドはインスタンスに存在しません。 それらはクラス/コンストラクター関数にのみ存在するため、そのインターフェースでのみ記述される必要があります。

クラスのインスタンスでは、静的メソッドはインスタンスに存在しません。

それについて詳しく説明してもらえますか？ これはC＃ではありません

それらはクラス/コンストラクター関数にのみ存在するため、そのインターフェースでのみ記述される必要があります。

私たちがそれを手に入れたこと、そしてそれが私たちが変えたいものです。

インターフェイスは、クラスを実装することによって実行されるコントラクトを定義します。 これは、インターフェースがクラスよりも高いレベルの抽象化であることを意味します。

私はそれに完全に同意します。 Jsonインターフェースの例を参照してください

こんにちは@kitsonk 、詳細を教えてください：

クラスには2つのインターフェースと2つの実装コントラクトがあり、それから逃れることはできません。

その部分がわかりませんでした。

論理的には、インターフェースはオブジェクトのパブリックサーフェスです。 インターフェイスは、オブジェクトのパブリックサーフェスを記述します。 つまり、そこにないものは何も含まれていません。

同意します。 私が言ったことと矛盾は見られません。 私ももっと言いました。 インターフェースは、クラスが履行されるための契約であると言いました。

クラスのインスタンスでは、静的メソッドはインスタンスに存在しません。 それらはクラス/コンストラクター関数にのみ存在するため、そのインターフェースでのみ記述される必要があります。

私がこの権利を理解したかどうかはわかりません。それが何を言っているかは明らかですが、なぜあなたがそれを言うのかはわかりません。 私の発言がまだ有効だと思う理由を説明できます。 私は常にインターフェイスをパラメータとしてメソッドに渡しています。つまり、インターフェイスメソッドにアクセスできます。ここでは、データ構造を定義する方法としてインターフェイスを使用しているのではなく、他の場所で作成/水和される具体的なオブジェクトを定義していることに注意してください。 。 だから私が持っているとき：

fetchData(account: SalesRepresentativeInterface): Observable<Array<AccountModel>> {
    // Method Body
}

そのメソッド本体では、実際にaccountメソッドを使用できます。 私ができるようにしたいのは、 accountで受け取っているクラスにすでに実装されている、 SalesRepresentativeInterfaceの静的メソッドを使用できるようにすることです。 たぶん、私はこの機能の使い方について非常に単純な、または完全に間違った考えを持っています。

static修飾子を許可すると、次のようなことができると思います： SalesRepresentativeInterface.staticMethodCall()

私が間違っている ？

乾杯

@davidmpaz ：構文は正しくありませんが、近いです。 使用パターンの例を次に示します。

interface JSONSerializable {
  static fromJSON(json: any): JSONSerializable;
  toJSON(): any;
}

function makeInstance<T extends JSONSerializable>(cls: typeof T): T {
  return cls.fromJSON({});
}

class ImplementsJSONSerializable implements JSONSerializable {
  constructor(private json: any) {
  }
  static fromJSON(json: any): ImplementsJSONSerializable {
    return new ImplementsJSONSerializable(json);
  }
  toJSON(): any {
    return this.json;
  }
}

// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializable);

残念ながら、これを機能させるには、TypeScriptの2つの機能が必要です。（1）インターフェイスの静的メソッドと抽象静的メソッド。 （2）ジェネリッククラスの型ヒントとしてtypeofを使用する機能。

@davidmpaz

その部分がわかりませんでした。

クラスには2つのインターフェースがあります。 コンストラクター関数とインスタンスのプロトタイプ。 キーワードclass本質的にそのための砂糖です。

interface Foo {
  bar(): void;
}

interface FooConstructor {
  new (): Foo;
  prototype: Foo;
  baz(): void;
}

declare const Foo: FooConstructor;

const foo = new Foo();
foo.bar();  // instance method
Foo.baz(); // static method

@jimmykane

それについて詳しく説明してもらえますか？ これはC＃ではありません

class Foo {
    bar() {}
    static baz() {}
}

const foo = new Foo();

foo.bar();
Foo.baz();

Fooのインスタンスには.baz()はありません。 .baz()はコンストラクターにのみ存在します。

タイプの観点から、この2つのインターフェースを参照/抽出できます。 Fooはパブリックインスタンスインターフェイスを参照し、 typeof Fooはパブリックコンストラクターインターフェイス（静的メソッドを含む）を参照します。

@kitsonkの説明をフォローアップするために、上記の例を書き直して、目的を達成します。

interface JSONSerializable <T>{
    fromJSON(json: any): T;
}

function makeInstance<T>(cls: JSONSerializable<T>): T {
    return cls.fromJSON({});
}

class ImplementsJSONSerializable {
    constructor (private json: any) {
    }
    static fromJSON(json: any): ImplementsJSONSerializable {
        return new ImplementsJSONSerializable(json);
    }
    toJSON(): any {
        return this.json;
    }
}

// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializable); 

ここで注意してください：

• implements句は実際には必要ありません。クラスを使用するたびに、構造チェックが実行され、必要なインターフェイスに一致するようにクラスが検証されます。
• コンストラクタータイプを取得するためにtypeofは必要ありません。 Tがキャプチャしようとしているものであることを確認してください。

@mhegazy ：JSONSerializableインターフェースでtoJSON呼び出しを削除する必要がありました。 私の単純なサンプル関数makeInstanceはfromJSON $のみを呼び出しますが、オブジェクトをインスタンス化してから使用することは非常に一般的です。 makeInstance内に$ Tが何であるかが実際にはわからないため、 makeInstanceから返されたものを呼び出す機能を削除しました（特にmakeInstanceの場合に関連します）

interface JSONSerializer {
  toJSON(): any;
}

interface JSONSerializable <T extends JSONSerializer> {
  fromJSON(json: any): T;
}

function makeInstance<T extends JSONSerializer>(cls: JSONSerializable<T>): T {
  return cls.fromJSON({});
}

class ImplementsJSONSerializer implements JSONSerializer {
  constructor (private json: any) {
  }
  static fromJSON(json: any): ImplementsJSONSerializer {
    return new ImplementsJSONSerializer(json);
  }
  toJSON(): any {
    return this.json;
  }
}

// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializer);

そして今、私のTには、 JSONSerializerで利用可能なすべてのメソッドがあることがわかりました。 しかし、これは非常に冗長で、推論するのが困難です（待って、 ImplementsJSONSerializerを渡しますが、これはJSONSerializableではありませんか？待ってください、あなたはダックタイピングですか??） 。 バージョンについてのより簡単な理由は次のとおりです。

interface JSONSerializer {
  toJSON(): any;
}

interface JSONSerializable <T extends JSONSerializer> {
  fromJSON(json: any): T;
}

function makeInstance<T extends JSONSerializer>(cls: JSONSerializable<T>): T {
  return cls.fromJSON({});
}

class ImplementsJSONSerializer implements JSONSerializer {
  constructor (private json: any) {
  }
  toJSON(): any {
    return this.json;
  }
}

class ImplementsJSONSerializable implements JSONSerializable<ImplementsJSONSerializer> {
  fromJSON(json: any): ImplementsJSONSerializer {
    return new ImplementsJSONSerializer(json);
  }

}

// returns an instance of ImplementsJSONSerializable
makeInstance(new ImplementsJSONSerializable());

しかし、前のコメントで指摘したように、インスタンス化するすべてのクラスに対してファクトリクラスを作成する必要があります。これは、ダックタイピングの例よりもさらに冗長です。 これは確かにJavaで常に実行可能なパターンです（C＃も想定しています）。 しかし、それは不必要に冗長で重複しています。 インターフェイスで静的メソッドが許可され、抽象クラスで抽象静的メソッドが許可されている場合、その定型文はすべてなくなります。

追加のクラスは必要ありません。 クラスにはstaticメンバーを含めることができます。 implements句は必要ありません。 記名的型システムでは、クラスで「isa」関係を表明するために本当に必要です。 構造型システムでは、実際には必要ありません。 「isa」の関係はとにかく使用するたびにチェックされるので、安全性を失うことなく、 implements句を安全に削除できます。

つまり、静的なfromJSONを持ち、インスタンスにtoJSONを持つ1つのクラスを持つことができます。

interface JSONSerializer {
    toJSON(): any;
}

interface JSONSerializable<T extends JSONSerializer> {
    fromJSON(json: any): T;
}

function makeInstance<T extends JSONSerializer>(cls: JSONSerializable<T>): T {
    return cls.fromJSON({});
}

class ImplementsJSONSerializer {
    constructor (private json: any) {
    }
    static fromJSON(json: any): ImplementsJSONSerializer {
        return new ImplementsJSONSerializer(json);
    }
    toJSON(): any {
        return this.json;
    }
}


// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializer);

@mhegazy私はすでにそれを実行可能な選択肢として指摘しました。 私の最初の「ダックタイピング」の例を参照してください。 私は、それが不必要に冗長であり、推論するのが難しいと主張しました。 次に、推論しやすいバージョン（ファクトリークラス）はさらに冗長であると主張しました。

インターフェイスに静的メソッドがないことを回避できることに異議を唱える人は誰もいません。 実際、私は、ファクトリクラスよりも機能的なスタイルを使用することで、よりエレガントな回避策があると主張しますが、それは私の個人的な好みです。

しかし、私の見解では、この非常に一般的なパターンを実装する方法について最もクリーンで最も簡単な理由は、抽象静的メソッドを使用することです。 他の言語（Python、PHP）でこの機能を気に入った人は、TypeScriptでこの機能を利用できません。 御時間ありがとうございます。

次に、推論しやすいバージョン（ファクトリークラス）を主張しました

これが推論しやすいことに同意するかどうかはわかりません。

しかし、私の見解では、この非常に一般的なパターンを実装する方法について最もクリーンで最も簡単な理由は、抽象静的メソッドを使用することです。 他の言語（Python、PHP）でこの機能を気に入った人は、TypeScriptでこの機能を利用できません。

そして、この問題はこれを追加することを追跡しています。 このスレッドへの将来の訪問者に、これがimplements句なしで今日実行可能であることを理解してもらいたかっただけです。

@kitsonkそうですね。

みんな、私はLocationModuleが好きです。これには、データベースに格納するオプションを取得するためのメソッドがあり、そこからそれ自体を再作成する必要があります。
すべてのLocationModuleには、レクリエーション用のタイプを持つ独自のオプションがあります。

そのため、レクリエーション用のジェネリックスを使用してファクトリを作成する必要がありますが、それでもコンパイル時のチェックはありません。 あなたが知っている、ここで目的を打ち負かす。

最初は「インターフェイスに静的なものがないので、抽象クラスに固執しましょう。しかし、コードタイプのあらゆる場所をインターフェイスから抽象クラスに変更して、チェッカーが探しているメソッドを認識できるようにする必要があるため、これでも汚れます。 。

ここ：

export interface LocationModuleInterface {
  readonly name: string;

  getRecreationOptions(): ModuleRecreationOptions;
}

export abstract class AbstractLocationModule implements LocationModuleInterface {
  abstract readonly name: string;

  abstract getRecreationOptions(): ModuleRecreationOptions;

  abstract static recreateFromOptions(options: ModuleRecreationOptions): AbstractLocationModule;
}

そして、私はよくつまずきます、静的は抽象であるはずがありません。 そして、それはインターフェースにあることはできません。

みんな、真剣に、これを実装しないことだけのためにこれを実装しないことを保護していませんか？

TypeScriptが大好きです。 狂ったように私は意味します。 しかし、常にあります。

静的メソッドの実装を強制する代わりに、単純な古いJavaScriptですべてを行っているように再確認する必要があります。

アーキテクチャはすでにパターンやクールな決定などでいっぱいですが、それらのいくつかは、インターフェイスの静的メソッドのような単純なものを使用する際の問題を克服するためのものです。

私のファクトリは、実行時に静的メソッドの存在を確認する必要があります。 どうですか？

またはさらに良い：

export interface LocationModuleInterface {
  readonly name: string;

  getRecreationOptions(): ModuleRecreationOptions;
  dontForgetToHaveStaticMethodForRecreation();
}

クラスオブジェクトを多態的に使用している場合、これがインターフェイスを実装する唯一の理由であり、クラスの静的側の要件を指定するインターフェイスがクラス自体によって構文的に参照されているかどうかは関係ありません。使用サイトでチェックされ、必要なインターフェースが実装されていない場合は設計時エラーが発生するためです。

@ malina-kirn

私の最初の「ダックタイピング」の例を参照してください。

この問題は、ダックタイピングが使用されているかどうかには関係ありません。 TypeScriptはダックタイピングです。

@aluanhaddadあなたの含意は正しくありません。 implements ISomeInterfaceの主な関数は、クラスオブジェクトを多態的に使用するためのものであるというあなたの指摘を理解できます。 ただし、クラスがクラスオブジェクトの静的な形状を記述するインターフェイスを参照するかどうかは重要です。

暗黙の型推論と使用サイトのエラーがすべてのユースケースをカバーしていることを意味します。
この例を考えてみましょう。

interface IComponent<TProps> {
    render(): JSX.Element;
}

type ComponentStaticDisplayName = 'One' | 'Two' | 'Three' | 'Four';
interface IComponentStatic<TProps> {
    defaultProps?: Partial<TProps>;
    displayName: ComponentStaticDisplayName;
    hasBeenValidated: 'Yes' | 'No';
    isFlammable: 'Yes' | 'No';
    isRadioactive: 'Yes' | 'No';
    willGoBoom: 'Yes' | 'No';
}

interface IComponentClass<TProps> extends IComponentStatic<TProps> {
    new (): IComponent<TProps> & IComponentStatic<TProps>;
}

function validateComponentStaticAtRuntime<TProps>(ComponentStatic: IComponentStatic<TProps>, values: any): void {
    if(ComponentStatic.isFlammable === 'Yes') {
        // something
    } else if(ComponentStatic.isFlammable === 'No') {
        // something else
    }
}

// This works, we've explicitly described the object using an interface
const componentStaticInstance: IComponentStatic<any> = {
    displayName: 'One',
    hasBeenValidated: 'No',
    isFlammable: 'Yes',
    isRadioactive: 'No',
    willGoBoom: 'Yes'
};

// Also works
validateComponentStaticAtRuntime(componentStaticInstance, {});

class ExampleComponent1 implements IComponent<any> {
    public render(): JSX.Element { return null; }

    public static displayName = 'One'; // inferred as type string
    public static hasBeenValidated = 'No'; // ditto ...
    public static isFlammable = 'Yes';
    public static isRadioactive = 'No';
    public static willGoBoom = 'Yes';
}

// Error: " ... not assignable to type IComponentStatic<..> ... "
validateComponentStaticAtRuntime(ExampleComponent1, {});

class ExampleComponent2 implements IComponent<any> {
    public render(): JSX.Element { return null; }

    public static displayName = 'One';
    public static hasBeenValidated = 'No';
    public static isFlammable = 'Yes';
    public static isRadioactive = 'No';
    public static willGoBoom = 'Yes';
}

// Error: " ... not assignable to type IComponentStatic<..> ... "
validateComponentStaticAtRuntime(ExampleComponent2, {});

上記の例では、明示的な型宣言が必要です。 クラスオブジェクト（静的側）の形状を記述しないと、実際の値が期待される形状に一致していても、使用サイトで設計時エラーが発生します。

さらに、静的な側面を説明するインターフェースを参照する方法がないため、個々のメンバーごとに型を明示的に宣言するしか選択肢がありません。 その後、すべてのクラスでそれを繰り返します。

以前の投稿に基づいて、インターフェイスのstatic修飾子は、解決する必要のあるいくつかのユースケースに対する非常に優れたソリューションであると感じています。 このコメントが大きくなってしまったことをお詫びしますが、説明したいことがたくさんあります。

1）上記の例のように、クラスオブジェクトの静的な側面の形状を明示的に記述できる必要がある場合があります。
2）定義サイトでの形状チェックが非常に望ましい場合があります。たとえば、 @ OliverJAshの例のように、使用サイトがチェックされない外部コードにあり、定義サイトで形状チェックを行う必要がある場合があります。 。

2番目に関しては、私が読んだ多くの投稿は、使用サイトが十分すぎるほど形状チェックを示唆しています。 しかし、使用場所がはるか遠くの銀河モジュールにある場合、または使用場所がチェックされない外部の場所にある場合、これは明らかに当てはまりません。

他の投稿は、定義サイトでの形状チェックに#workaroundsを提案しています。 これらの恐ろしい回避策により、定義サイトで形状を確認できますが（場合によっては）、問題があります。

• これらは上記の1を解決しません。それでも、すべてのクラスの各メンバーで型を明示的に宣言する必要があります。
• 多くの場合、それらは明快さ、優雅さ、そして読みやすさを欠いています。 それらは必ずしも使いやすく、直感的ではなく、それらが可能であると理解するのにかなりの時間がかかる場合があります。
• それらはすべての場合に機能するわけではなく、 #workaroundsToMakeTheWorkaroundsWorkを見つけることは楽しいことではありません...または生産的です...しかしほとんどの場合楽しいことではありません。

これは、定義サイトで形状チェックを強制するために最近見た回避策の例です...

// (at least) two separate interfaces
interface ISomeComponent { ... }
interface ISomeComponentClass { ... }

// confusing workaround with extra work to use, not very intuitive, etc
export const SomeComponent: ISomeComponentClass =
class SomeComponent extends Component<IProps, IState> implements ISomeComponent {
...
}

次に、抽象クラスをスローして、その回避策を使用してみてください

interface ISomeComponent { ... }
// need to separate the static type from the class type, because the abstract class won't satisfy
// the shape check for new(): ... 
interface ISomeComponentStatic { ... }
interface ISomeComponentClass { 
    new (): ISomeComponent & ISomeComponentStatic;
}

// I AM ERROR.    ... cannot find name abstract
export const SomeComponentBase: ISomeComponentStatic =
abstract class SomeComponentBase extends Component<IProps, IState> implements ISomeComponent {
...
}

export const SomeComponent: ISomeComponentClass =
class extends SomeComponentBase { ... }

私たちもそれを回避すると思います...ため息

...

abstract class SomeComponentBaseClass extends Component<IProps, IState> implements ISomeComponent { 
   ... 
}

// Not as nice since we're now below the actual definition site and it's a little more verbose
// but hey at least were in the same module and we can check the shape if the use site is in
// external code...
// We now have to decide if we'll use this work around for all classes or only the abstract ones
// and instead mix and match workaround syntax
export const SomeComponentBase: ISomeComponentStatic = SomeComponentBaseClass;

しかし、待ってください、もっとあります！ ジェネリックを使用している場合に何が起こるか見てみましょう。

interface IComponent<TProps extends A> { ... }
interface IComponentStatic<TProps extends A> { ... }

interface IComponentClass<TProps extends A, TOptions extends B> extends IComponentStatic<TProps> {
    new (options: TOptions): IComponent<TProps> & IComponentStatic<TProps>;
}

abstract class SomeComponentBaseClass<TProps extends A, TOptions extends B> extends Component<TProps, IState> implements IComponent<TProps> {
...
}

// Ruh Roh Raggy: "Generic type .... requires 2 type argument(s) ..."
export const SomeComponentBase: IComponentStatic = SomeComponentBaseClass;


// "....  requires 1 type argument(s) ... "    OH NO, We need a different workaround
export const SomeComponent: IComponentStatic =
class extends SomeComponentBase<TProps extends A, ISomeComponentOptions> {
...
}

この時点で、typescriptによってチェックされるコード内の使用サイトがある場合は、弾丸をかじって、それが本当に遠くにある場合でも、それを信頼する必要があります。

サイトを外部で使用している場合は、コミュニティ/メンテナにインターフェイスメンバーのstatic修飾子を受け入れるように説得してください。 それまでの間、別の回避策が必要になります。 定義サイトにはありませんが、＃8328で説明されている回避策の修正バージョンを使用してこれを実現できると思います。 @RyanCavanaughの厚意により、2016年5月16日の@mhegazyからのコメントで回避策を参照してください。

重要なポイントが欠けている場合はご容赦ください。 インターフェイスメンバーのstaticをサポートすることをためらうことについての私の理解は、主に、コンストラクターの形状とインスタンスの形状の両方を記述するために同じインターフェイス+ implementsキーワードを使用することを嫌うことです。

次の例えの前に、typescriptが提供するものが大好きで、typescriptを開発した人々と、多数の機能要求に対処するために多くの考えと努力を注いでいるコミュニティに感謝します。 最適な機能を実装するために最善を尽くしています。

しかし、この場合の躊躇は、使いやすさを犠牲にして「概念的な純粋さ」を維持したいという願望として私には見えます。 このアナロジーがベースから大きく外れている場合は、もう一度申し訳ありません。

これは、 JavaからC# $への切り替えを思い出させます。 C#コードがこれを実行しているのを最初に見たとき
C# var something = "something"; if(something == "something") { ... }
目覚ましベルが頭の中で鳴り始め、世界は終わりを告げ、 "something".Equals(something)などを使用する必要がありました

==は参照用です！ 文字列比較用に別の.Equals(...)があります...
そして、文字列リテラルが最初に来る必要があるので、null変数で.Equals（...）を呼び出すnullrefを取得しません。
そして...そして...過呼吸

そして、 C#を数週間使用した後、その動作のおかげで、どれほど使いやすいかがわかりました。 両者の明確な区別をあきらめることを意味していましたが、それは使いやすさを劇的に向上させるので、それだけの価値があります。

これが、インターフェイスメンバーのstatic修飾子についての私の気持ちです。 これにより、すでに行っているようにインスタンスの形状を記述し続けることができ、場合によっては不十分な回避策でのみ実行できるコンストラクター関数の形状を記述でき、比較的クリーンで簡単な両方を実行できます。仕方。 使いやすさの大幅な向上、IMO。

次のコメントでabstract staticを検討します。

インターフェイスは常に、強制的なクラスのメンバータイプの再指定を必要とします。 （_explicitly_実装クラスでのメンバー署名の推論は、別個の、まだサポートされていない機能です）。

エラーが発生する理由は、この提案とは関係ありません。 これを回避するには、静的またはその他のリテラル型である必要があるクラスメンバーの実装でreadonly修飾子を使用する必要があります。 それ以外の場合は、 stringが推測されます。

繰り返しますが、 implementsキーワードは単なる意図の仕様であり、型の構造的な互換性に影響を与えたり、名目上の型付けを導入したりすることはありません。 それが役に立たなかったというわけではありませんが、それはタイプを変更しません。

だからabstract static ...それだけの価値はありません。 問題が多すぎます。

使用サイトで暗黙的にチェックされるものを宣言するには、新しく複雑な構文が必要になります（使用サイトがtypescriptコンパイラによってチェックされる場合）。

使用サイトが外部の場合、本当に必要なのはインターフェイスのstaticメンバーです...プラグインを完了して申し訳ありません....そしておやすみなさい！

@aluanhaddad本当ですが、クラスを明示的に実装する際のメンバー署名の推論がサポートされている機能であったとしても、クラスの静的側のメンバー署名を宣言するクリーンな方法がありません。

私が表現しようとしていたのは、クラスの静的側の予想される構造をexplicitly宣言する方法がなく、それが重要である（または機能をサポートするために重要になる）場合があるということでした。

主に、コメントのこの部分について、「クラスの静的側の要件を指定するインターフェースが構文的に参照されているかどうかは関係ありません」と反論したいと思います。

将来のサポートで重要になる理由の例として、型推論を使用しようとしていました。
ここでインターフェースを構文的に参照することにより、 let something: ISomethingStatic = { isFlammable: 'Ys', isFlammable2: 'No' ... isFlammable100: 'No' }は、型を「はい」として明示的に宣言する必要はありません。 「いいえ」100回。

（将来的に）クラスの静的側で同じ型推論を実現するには、インターフェースを構文的に参照する方法が必要になります。

あなたの最新のコメントを読んだ後、それは私が望んでいたほど明確な例ではなかったと思います。 おそらくより良い例は、クラスの静的側の使用サイトが、typescriptコンパイラによってチェックされない外部コードにある場合です。 このような場合、現在、基本的に人工的な使用サイトを作成し、使いやすさや読みやすさを低下させ、多くの場合は機能しない回避策に依存する必要があります。

ある程度の冗長性を犠牲にして、適切なレベルの型安全性を達成できます。

type HasType<T, Q extends T> = Q;

interface IStatic<X, Y> {
    doWork: (input: X) => Y
}

type A_implments_IStatic<X, Y> = HasType<IStatic<X, Y>, typeof A>    // OK
type A_implments_IStatic2<X> = HasType<IStatic<X, number>, typeof A> // OK
type A_implments_IStatic3<X> = HasType<IStatic<number, X>, typeof A> // OK
class A<X, Y> {
    static doWork<T, U>(_input: T): U {
        return null!;
    }
}

type B_implments_IStatic = HasType<IStatic<number, string>, typeof B> // Error as expected
class B {
    static doWork(n: number) {
        return n + n;
    }
}

これは許可されるべきであることに同意しました。 次の単純なユースケースは、抽象静的メソッドの恩恵を受けます。

export abstract class Component {
  public abstract static READ_FROM(buffer: ByteBuffer): Component;
}

// I want to force my DeckComponent class to implement it's own static ReadFrom method
export class DeckComponent extends Component {
  public cardIds: number[];

  constructor(cardIds: number[]) {
    this.cardIds = cardIds;
  }

  public static READ_FROM(buffer: ByteBuffer): DeckComponent {
    const cardIds: number[] = [...];
    return new DeckComponent(cardIds);
  }
}

@RyanCavanaughまだ誰もこれについて正確に言及していないと思いますが（私のクイックリードスルーでは見逃していた可能性がありますが）、次のように応答します。

これを検討するときに私たちが持っていた主な質問：誰が抽象静的メソッドを呼び出すことができますか？ おそらく、AbstractParentClass.getSomeClassDependentValueを直接呼び出すことはできません。 しかし、AbstractParentClass型の式でメソッドを呼び出すことはできますか？ もしそうなら、なぜそれが許可されるべきですか？ そうでない場合、この機能の用途は何ですか？

これは、＃3841の一部を実装することで対処できます。 その問題を読むと、提起された主な異論は、派生クラスのコンストラクター関数のタイプが、基本クラスのコンストラクター関数と互換性がないことが多いということのようです。 ただし、TypeScriptは、オーバーライドされた静的メソッドが基本クラスの型と互換性があることをすでにチェックしているため、同じ懸念が他の静的メソッドまたはフィールドには当てはまらないようです。

したがって、私が提案するのは、 T.constructorにタイプFunction & {{ statics on T }}を与えることです。 これにより、 abstract static fooフィールドを宣言する抽象クラスは、コンストラクターの非互換性の問題を引き起こさずに、 this.constructor.fooを介して安全にアクセスできるようになります。

また、静的関数をT.constructorに自動的に追加することが実装されていない場合でも、手動で"constructor": typeof AbstractParentClassを宣言することにより、基本クラスでabstract staticプロパティを使用できます。

多くの人が@ patryk-zielinski93の例が機能することを期待していると思います。 代わりに、直感に反する、冗長で不可解な回避策を使用する必要があります。 すでに「構文糖化」クラスと静的メンバーがあるのに、なぜそのような糖を型システムに含めることができないのでしょうか。

これが私の痛みです：

abstract class Shape {
    className() {
        return (<typeof Shape>this.constructor).className;
    }
    abstract static readonly className: string; // How to achieve it?
}

class Polygon extends Shape {
    static readonly className = 'Polygon';
}

class Triangle extends Polygon {
    static readonly className = 'Triangle';
}

代わりに/並行してstatic implements句を導入できますか？ 例えば

interface Foo {
    bar(): number;
}

class Baz static implements Foo {
    public static bar() {
        return 4;
    }
}

これには、静的メンバーとインスタンスメンバーに別々のインターフェイスを宣言することで下位互換性があるという利点があります。これは、このスレッドを正しく読んでいる場合、現在選択されている回避策のようです。 それ自体が有用であると私が見ることができた微妙に異なる機能でもありますが、それは重要ではありません。

（ statically implementsの方が良いでしょうが、それは新しいキーワードを導入します。これがその価値があるかどうかは議論の余地があります。しかし、それは文脈的かもしれません。）

OPの提案に懐疑的な人たちの議論をどんなに理解しようとしても失敗しました。

@RyanCavanaughに回答したのは1人だけ（https://github.com/Microsoft/TypeScript/issues/14600#issuecomment-379645122）です。 OPのコードを書き直して、少しわかりやすくし、質問と回答を説明しました。

abstract class Base {
  abstract static foo() // ref#1
}

class Child1 extends Base {
  static foo() {...} // ref#2
}

class Child2 extends Base {
  static foo() {...}
}

誰が抽象静的メソッドを呼び出すことができますか？ おそらく、 Base.fooを直接呼び出すことはできません

ref＃1を意味する場合は、そうです。抽象的であり、本体さえないため、呼び出し可能であってはなりません。
ref＃2のみを呼び出すことができます。

しかし、Base型の式でメソッドを呼び出すことはできますか？
もしそうなら、なぜそれが許可されるべきですか？

function bar(baz:Base) { // "expression of type Base"
  baz.foo() // ref#3
}

function bar2(baz: typeof Base) { // expression of type Base.constructor
  baz.foo() // ref#4
}

ref＃3はエラーです。 いいえ、そこで「foo」を呼び出すことはできません。 bazはChild1またはChild2の__instance__であると想定されており、インスタンスには静的メソッドがないためです。

ref＃4は正しい（正しいはずです）。 bazは、Baseを拡張するChild1またはChild2のコンストラクターであると想定されているため、そこで静的メソッドfooを呼び出すことができます（できるはずです）。したがって、foo（）を実装する必要があります。

bar2(Child1) // ok
bar2(Child2) // ok

あなたはこの状況を想像することができます：

bar2(Base) // ok, but ref#4 should be red-highlighted with compile error e.g. "Cannot call abstract  method." 
// Don't know if it's possible to implement in compiler, though. 
// If not, compiler simply should not raise any error and let JS to do it in runtime (Base.foo is not a function). 

この機能の用途は何ですか？

ref＃4を参照してください。引数として受け取る子クラス（Child1またはChild2の可能性があります）がわからないが、静的メソッドを呼び出して、そのメソッドが存在することを確認する場合に使用します。
私はAdonisJSと呼ばれるnode.jsフレームワークを正しく書き直しています。 純粋なJSで書かれているので、TSに変換しています。 コードの動作を変更することはできません。タイプを追加するだけです。 この機能がないので、とても悲しくなります。

psこのコメントでは、簡単にするために、抽象クラスについてのみ記述し、インターフェースについては言及しませんでした。 しかし、私が書いたものはすべてインターフェースに適用できます。 抽象クラスをインターフェースに置き換えるだけで、すべてが正しくなります。 何らかの理由で（理由がわからない）TSチームがabstract classにabstract staticを実装したくない場合は、可能性がありますが、 staticのみを実装することは問題ありません。インターフェイスの単語、それは私たちを十分に幸せにするでしょう、私は推測します。

pps質問のクラス名とメソッド名を編集して、コードに準拠させました。

他の懐疑論者の主な議論に基づいたいくつかの考え：

「いいえ、これは実装してはいけませんが、すでにこの方法で実装できます* 15倍以上のコード行を記述します*」。

それが構文糖衣のために作られているものです。 TSに少し（砂糖）を加えましょう。 しかし、いいえ、インターフェイスに1つの単純なstatic単語を追加するのではなく、デコレータと数十のジェネリックを突破しようとする開発者の頭脳を拷問したほうがよいでしょう。 そのstaticを私たちの生活を楽にする別の砂糖と考えてみませんか？ ES6がclassを追加するのと同じ方法で（これは最近ユビキタスになります）。 しかし、いいえ、私たちはオタクになり、古くて「正しい」方法で物事を行いましょう。

「jsクラスには、コンストラクターとインスタンスの2つのインターフェースがあります」。

では、コンストラクターのインターフェースを作成する方法を教えてください。 ただし、そのstatic単語を追加するだけで、はるかに簡単で直感的になります。

そしてこれに関して：

それについてのフィードバックがさらに聞こえるまで、これを保留します。

この問題がいつまで延期されるのか、1年以上が経過し、多くのフィードバックが提供されましたか？ 誰かが答えてもらえますか？

この投稿はちょっと厳しいように思えるかもしれません...しかし、いいえ、それはTSを愛する人からの要求であり、同時に、古いJSコードベースをTSに変換するときに、醜いハックを行うべき理由を1つ見つけることができません。 これとは別に、TSチームに感謝します。 TSは素晴らしいです。それは私の人生を変え、コーディングと仕事をこれまで以上に楽しんでいます...しかし、この問題は私の経験を害しています。

考えられる回避策は？

export type Constructor<T> = new (...args: any[]) => T;

declare global {
  interface Function extends StaticInterface {
  }
}

export interface StaticInterface {
  builder: (this: Constructor<MyClass>) => MyClass
}

// TODO add decorator that adds "builder" implementation
export class MyClass {
  name = "Ayyy"
}

export class OtherClass {
  id = "Yaaa"
}

MyClass.builder() // ok
OtherClass.builder() // error

提案：インターフェースと型の静的メンバー、および抽象クラスの抽象メンバー、v2

ユースケース

ファンタジーランド準拠のタイプ

`` `` typescript
interface Applicative extends Apply {（a：A）の静的：適用可能; }

const of = >（c：C、a：A）：new C => c.of（a）; `` ``

静的deserializeメソッドを使用したSerializableタイプ

`` `` typescript
インターフェイスSerializable {
static deserialize（s：string）：Serializable;

serialize(): string;

}
`` ``

契約全般

`` `` typescript
インターフェイス契約{
static create（x：number）：契約;
static new（x：number）：契約;
}

const factory1 =（c：静的コントラクト）：コントラクト=> c.create（Math.random（））;
const factory2 =（C：静的コントラクト）：コントラクト=> new C（Math.random（））;
const factory3 =（c：C）：新しいC => c.create（Math.random（））;

const c1 = factory1（ContractImpl）; // Contract
const c2 = factory2（ContractImpl）; // Contract
const c3 = factory3（ContractImpl）; // ContractImpl
`` ``

構文

静的メソッドとフィールド

`` `` typescript
インターフェイスSerializable {
static deserialize（s：string）：Serializable;
}

タイプSerializable = {
static deserialize（s：string）：Serializable;
};

抽象クラスSerializable {
static abstract deserialize（s：string）：Serializable;
}
`` ``

静的コンストラクターの署名

typescript interface Contract { static new(): Contract; }

後続：静的コールシグネチャ

議論：

静的な呼び出し署名はどのように表現できますか？
呼び出し署名の前にstatic修飾子を追加するだけでそれらを表現する場合、
'static'という名前のインスタンスメソッドとどのように区別しますか？
'new'という名前のメソッドと同じ回避策を使用できますか？
そのような場合、それは間違いなく重大な変化になります。

static型演算子

typescript const deserialize = (Class: static Serializable, s: string): Serializable => Class.deserialize(s);

new型演算子

typescript const deserialize = <C extends static Serializable>(Class: C, s: string): new C => Class.deserialize(s);

内部スロット

[[Static]]内部スロット

タイプの「静的」インターフェースは、 [[Static]]内部スロットに格納されます。

`` `` typescript
// タイプ
インターフェイスSerializable {
static deserialize（s：string）：Serializable;
シリアル化：文字列;
}

//内部的に次のように表されます
//インターフェースSerializable {
// [[静的]]：{
// [[Instance]]：Serializable; // 下記参照。
// deserialize（s：string）：Serializable;
//};
// serialize（）：string;
//}
`` ``

デフォルトでは、タイプneverです。

[[Instance]]内部スロット

タイプの「インスタンス」インターフェースが保存されます
[[Static]]内部スロットタイプの[[Instance]]内部スロット。

デフォルトでは、タイプneverです。

セマンティクス

static演算子なし

型を値型として使用する場合、
[[Static]]内部スロットは破棄されます：

`` `` typescript
const serializableを宣言します：Serializable;

タイプT =シリアル化可能なタイプ。
// {serialize（）：string; }
`` ``

ただし、タイプ自体は[[Static]]内部スロットを保持したままです。

typescript type T = Serializable; // { // [[Static]]: { // [[Instance]]: Serializable; // deserialize(s: string): Serializable; // }; // serialize(): string; // }

割り当て可能性

静的認識タイプの両方の値は、構造的に同一に割り当てることができます
（もちろん、 [[Static]]を除く）ものとその逆。

static演算子

| 結合性| 優先順位|
| ：-----------：| ：--------------------------------：|
| 右| IDKですが、 newのものと同じです|

static型演算子は、型の[[Static]]内部スロットの型を返します。
typeof型演算子にいくぶん似ていますが、
ただし、引数は値ではなく型である必要があります。

typescript type T = static Serializable; // { // [[Instance]]: Serializable; // deserialize(s: string): Serializable; // }

typeof型演算子は、 [[Instance]]内部スロットも破棄します。

`` `` typescript
const SerializableImplを宣言します：static Serializable;

タイプT = typeof SerializableImpl;
// {deserialize（s：string）：Serializable; }
`` ``

割り当て可能性

インスタンス対応タイプの両方の値は、構造的に同一に割り当てることができます
（もちろん、 [[Instance]]内部スロットを除く）ものとその逆。

new演算子

| 結合性| 優先順位|
| ：-----------：| ：-----------------------------------：|
| 右| IDKですが、 staticのものと同じです|

new演算子は、タイプの[[Instance]]内部スロットのタイプを返します。
static演算子を効果的に逆にします。

typescript type T = new static Serializable; // { // [[Static]]: { // [[Instance]]: Serializable; // deserialize(s: string): Serializable; // }; // serialize(): string; // }

extends / implementsセマンティクス

デフォルト以外の[[Static]]内部スロットを持つインターフェースを実装するクラス
互換性のある[[Static]]内部スロットが必要です。
互換性チェックは、と同じ（または類似）である必要があります
定期的な（インスタンス）互換性チェック。

`` `` typescript
クラスSerializableImplはSerializable {を実装します
static deserialize（s：string）：SerializableImpl {
//逆シリアル化ロジックはここにあります。
}

// ...other static members
// constructor
// ...other members

serialize(): string {
    //
}

}
`` ``

TODO

• []静的呼び出しシグニチャに使用する構文を決定します。
  おそらく変更を壊すことなく。
• []条件付きタイプとinfer演算子を使用した特殊なケースはありますか？
• []非抽象クラスメンバーのセマンティクスへの変更。 _壊れている可能性があります。_

この問題と他の問題を数時間かけて読んで、問題の回避策を見つけました。これは、静的修飾子またはクラスのインターフェイスによって解決されます。 問題を解決する回避策が1つも見つかりません。

私が抱えている問題は、コードで生成されたクラスに変更を加えたいということです。 たとえば、私がやりたいことは次のとおりです。

import {Message} from "../protobuf";

declare module "../protobuf" {
    interface Message {
        static factory: (params: MessageParams) => Message
    }
}

Message.factory = function(params: MessageParams) {
    const message = new Message();
    //... set up properties
    return message;
}

export default Message;

現在のバージョンのTSで、これと同等の回避策を1つ見つけることができません。 現在、この問題を解決する方法がありませんか？

これは、明らかに回避策がなく、確かに簡単な回避策がないユースケースとしてここに投稿することに関連していると感じます。

クラスのインスタンスと静的側をインターフェースと照合する場合は、次のように行うことができます。

interface C1Instance {
  // Instance properties ...

  // Prototype properties ...
}
interface C2Instance extends C1Instance {
  // Instance properties ...

  // Prototype properties ...
}

interface C1Constructor {
  new (): C1Instance;

  // Static properties ...
}
interface C2Constructor {
  new (): C2Instance;

  // Static properties ...
}

type C1 = C1Instance;
let C1: C1Constructor = class {};

type C2 = C2Instance;
let C2: C2Constructor = class extends C1 {};

let c1: C1 = new C1();
let c2: C2 = new C2();

あまりにも多くの人が、これに多くの時間を費やしている。 なんでそんなことないの？！¿i！
読みやすく、消化しやすく、簡単な1ライナーである必要があるものに対する、すべての大きな回避策の答えはなぜですか。 私のコードがハッキーな回避策で何をしようとしているのかを誰かに理解させてほしいという方法はありません。 このトピックをあまり価値のないものでさらに混乱させて申し訳ありませんが、それは現在非常に苦痛で時間の無駄なので、私、現在の他の人、そして後で答えを探している人にとっては価値があると思います。

自然と人工の両方の言語で、効率的で使用するのに魅力的なものになるように自然に進化する必要があるもの。 最終的に、人々は言語の削減を使用することを決定し（ "okay" => "ok"、 "going to" => "gonna"）、 "selfie"や "google"などの新しいばかげた単語を発明し、l33tspeakでスペルを再定義しました。もの、そしていくつかの単語を禁止することさえあります、そしてあなたがそれらを使いたいかどうかにかかわらず、誰もがそれが何を意味するかをまだ少し理解しています、そして私たちの何人かは特定のどんなタスクを達成するためにそれらを使います。 そして、それらのどれにも正当な理由はありませんが、特定のタスクにおける特定の人々の効率は、実際にそれらを利用する人々の数の問題です。 この会話の量は、多くの人々がこのstatic abstractを、彼らが持っているどんなひどい考慮事項にも利用できることを明確に示しています。 同じ理由でここに来ました。 ' Serializableを実装したかったので、直感的な（私にとって）すべての方法を試しましたが、どれも機能しませんでした。 私を信じてください、私が探す最後のことは、なぜ私がこの機能を必要とせず、何か他のものを探すべきなのかという説明です。 一年半、イエス・キリスト！ 私は、テストなどを備えたPRがすでにどこかにあるに違いありません。 これを実現してください。推奨されない特定の使用方法がある場合は、そのためのtslintがあります。

this.constructor.staticMemberを介して基本クラスから子クラスの静的メンバーにアクセスすることが可能であるため、抽象静的メンバーは私には理にかなっています。

class A {
  f() {
    console.log(this.constructor.x)
  }
}

class B extends A {
  static x = "b"
}

const b = new B
b.f() // logs "b"

クラスAは、静的なxメンバーが必要であることを指定できる必要があります。これは、クラスAがfメソッドで使用するためです。

連絡あった ？
機能は本当に必要です😄
1）インターフェイスのstatic関数
2）抽象クラスのabstract static関数

私は静的インターフェースを持つという考えは嫌いですが、すべての実用的な目的のために、今日は以下で十分なはずです：

type MyClass =  (new (text: string) => MyInterface) & { myStaticMethod(): string; }

次のように使用できます。

const MyClass: MyClass = class implements MyInterface {
   constructor(text: string) {}
   static myStaticMethod(): string { return ''; }
}

アップデート：

アイデアと実際の例の詳細：

// dynamic part
interface MyInterface {
    data: number[];
}
// static part
interface MyStaticInterface {
    myStaticMethod(): string;
}

// type of a class that implements both static and dynamic interfaces
type MyClass = (new (data: number[]) => MyInterface) & MyStaticInterface;

// way to make sure that given class implements both 
// static and dynamic interface
const MyClass: MyClass = class MyClass implements MyInterface {
   constructor(public data: number[]) {}
   static myStaticMethod(): string { return ''; }
}

// works just like a real class
const myInstance = new MyClass([]); // <-- works!
MyClass.myStaticMethod(); // <-- works!

// example of catching errors: bad static part
/*
type 'typeof MyBadClass1' is not assignable to type 'MyClass'.
  Type 'typeof MyBadClass1' is not assignable to type 'MyStaticInterface'.
    Property 'myStaticMethod' is missing in type 'typeof MyBadClass1'.
*/
const MyBadClass1: MyClass = class implements MyInterface {
   constructor(public data: number[]) {}
   static myNewStaticMethod(): string { return ''; }
}

// example of catching errors: bad dynamic part
/*
Type 'typeof MyBadClass2' is not assignable to type 'MyClass'.
  Type 'typeof MyBadClass2' is not assignable to type 'new (data: number[]) => MyInterface'.
    Type 'MyBadClass2' is not assignable to type 'MyInterface'.
      Property 'data' is missing in type 'MyBadClass2'.
*/
const MyBadClass2: MyClass = class implements MyInterface {
   constructor(public values: number[]) {}
   static myStaticMethod(): string { return ''; }
}

@ aleksey-bykovこれはTypescriptのせいではないかもしれませんが、この動作するAngularコンポーネントデコレータとそのAoTコンパイラを取得できませんでした。

@ aleksey-bykovそれは賢いですが、それでも抽象静的には機能しません。 MyClassのサブクラスがある場合、それらは型チェックで強制されません。 ジェネリック医薬品が関係している場合もさらに悪化します。

// no errors
class Thing extends MyClass {

}

静的属性を必要とするエンドユーザーライブラリを構築することには合理的な実装がないため、TypeScriptチームがこれに対するスタンスを再検討することを本当に望んでいます。 インターフェイスの実装者/抽象クラスのエクステンダーに静的なものがあることを要求するコントラクトを作成できるはずです。

@bbugh私はここで議論されている問題の存在そのものに疑問を持っていますが、通常のクラスのインスタンスを介して同じことができるのであれば、静的抽象継承メソッドでこれらすべての問題が必要になるのはなぜですか？

class MyAbstractStaticClass {
    abstract static myStaticMethod(): void; // <-- wish we could
}
class MyStaticClass extends MyAbstractStaticClass {
    static myStaticMethod(): void {
         console.log('hi');
    }
}
MyStaticClass.myStaticMethod(); // <-- would be great

vs

class MyAbstractNonStaticClass {
    abstract myAbstractNonStaticMethod(): void;
}
class MyNonStaticClass extends MyAbstractNonStaticClass {
    myNonStaticMethod(): void {
        console.log('hi again');
    }
}
new MyNonStaticClass().myNonStaticMethod(); // <-- works today

@ aleksey-bykov理由はたくさんあります。 例（@ patryk-zielinski93から）：

abstract class Serializable {  
    abstract serialize (): Object;  
    abstract static deserialize (Object): Serializable;  
}  

Serializableのサブクラスに静的deserializeメソッドを強制的に実装したいと思います。
そのような動作を実装するための回避策はありますか？

編集：コンストラクターとしてdeserializeを使用することもできることは知っていますが、クラスは1つのコンストラクターしか持てないため、ファクトリメソッドが必要になります。 人々は、インターフェースにファクトリメソッドを要求する方法を望んでいます。これは完全に理にかなっています。

デシリアライズされるクラスそのものに静的デシリアライズメソッドをアタッチするメリットがないため、単にdesireizationロジックを別のクラスに持っていきます。

class Deserializer {
     deserializeThis(...): Xxx {}
     deserializeThat(...): Yyy {}
}

何が問題ですか？

@ aleksey-bykov別のクラスはきれいに見えません

@ aleksey-bykov、問題は、シリアル化が必要なクラスが複数あることです。そのため、あなたのアプローチは、uberclassアンチパターンであるシリアル化可能のディクショナリを作成することを余儀なくされており、それらのいずれかを変更するたびに、このuberclassで編集する必要があります。これにより、コードは厄介なものになります。 シリアル化可能なインターフェイスを使用すると、特定のオブジェクトタイプに実装を強制でき、ポリモーフィック継承もサポートできます。これが、人々が望む主な理由です。 利益があるかどうかを推測しないでください。誰もが選択肢を持ち、自分のプロジェクトにとって何が有益かを選択できるはずです。

@octaharonは、デシリアライズ専用のクラスを持っているので、あなたが言ったこととはまったく逆です。変更するのはデシリアライズを気にするときだけなので、単一責任があります。

反対に、提案したようにクラス自体に逆シリアル化を追加すると、クラスに追加の責任と変更の理由が追加されます

最後に、静的メソッドに問題はありませんが、抽象静的メソッドと静的インターフェイスの実際のユースケースの例を見て本当に興味があります

@octaharonは、デシリアライズ専用のクラスを持っているので、あなたが言ったこととはまったく逆です。変更するのはデシリアライズを気にするときだけなので、単一責任があります。

ただし、（逆）シリアル化は型の構造に依存するため、コードを1か所ではなく2か所で変更する必要があります。 それは「単一責任」にはカウントされません

反対に、提案したようにクラス自体に逆シリアル化を追加すると、クラスに追加の責任と変更の理由が追加されます

あなたの言っていることがわかりません。 独自の（逆）シリアル化を担当するクラスは、まさに私が望んでいるものです。それが正しいか間違っているかを教えないでください。

単一責任は、関係するファイルの数については何も述べておらず、単一の理由が必要であると述べているだけです。

私が言っているのは、新しいクラスを追加するときは、単に逆シリアル化される以外の目的でそれを意味するので、すでに存在する理由とそれに割り当てられた責任があるということです。 次に、それ自体を逆シリアル化できるという別の責任を追加します。これにより、2つの責任が発生します。これは、SOLIDに違反します。レンダリング、印刷、コピー、転送、暗号化などを追加し続けると、神のクラスを取得します。

そして、私があなたに平凡さを言うのを許してください、しかし利益と実際のユースケースについての質問（そして答え）はこの機能提案が実行されるように駆り立てるものです

SOLIDは、全能の神からタブレットで送信されたものではありません。送信されたとしても、その解釈にはある程度の自由度があります。 あなたはそれについてあなたが望むのと同じくらい理想主義的かもしれませんが、私にお願いします：あなたの信念をコミュニティに広めないでください。 誰もが自分の好きな方法でツールを使用し、自分が知っているすべての可能なルールを破るすべての権利を持っています（殺人のせいでナイフを責めることはできません）。 ツールの品質を定義するのは、特定の機能に対する需要とそれらに対する提供との間のバランスです。 そして、このブランチは需要の量を示しています。 この機能が必要ない場合は、使用しないでください。 私がやります。 そして、ここの多くの人々もそれを必要としています、そしてあなたが実際にそれを無視するべきであるとあなたが言っている間、_we_は実用的なユースケースを持っています。 それは、メンテナにとってより重要なこと、つまり聖なる原則（彼らがそれを理解する方法に関係なく）、またはコミュニティについてのみです。

男、良い提案機能のユースケースはありますが、これはそうではありません

だから私はいくつかの好奇心を表明して質問をしました、提案はそれを述べていないので、なぜあなたはそれを必要とするかもしれません

それは典型的なものに要約されます：ただ原因、あなたはあえてしないでください

個人的に私は固体やおっとを気にしません、私はちょうどずっと前にそれを大きくしすぎました、あなたは「uberclassアンチパターン」引数を投げることによってそれを持ち出し、そして「その解釈への自由度」にバックアップしました

このディスカッション全体で言及されている唯一の実際的な理由は次のとおりです： https ：//github.com/Microsoft/TypeScript/issues/14600#issuecomment -308362119

これが役立つ非常に一般的なユースケースは、displayName、propTypes、defaultPropsなどの静的プロパティを持つクラスであるReactコンポーネントです。

と同様のいくつかの投稿https://github.com/Microsoft/TypeScript/issues/14600#issuecomment-345496014

しかし、それは(new (...) => MyClass) & MyStaticInterfaceでカバーされています

それが正確なユースケースであり、私がここにいる理由です。 投票数はわかりますか？ practicalとそうでないものを決めるのは、なぜあなた自身の責任だと思いますか？ Practicalはpracticeに置くことができるものであり、（執筆時点で）83人がこの機能を非常に実用的だと思うでしょう。 フレーズを文脈から引き出してさまざまな流行語を展示する前に、他の人を尊重し、スレッド全体を読んでください。 あなたが克服したものが何であれ、それは間違いなくあなたのエゴではありません。

実用的なものは問題を解決するものであり、非実用的なものはあなたの美意識を刺激するものであるというのは常識です、私は他の人を尊重しますが、すべての点で質問（現在は主に修辞的です）がまだ保持されています：この提案はどのような問題を意図していますかhttps://github.com/Microsoft/TypeScript/issues/14600#issuecomment-308362119およびhttps://github.com/Microsoft/TypeScript/issues/14600#issuecomment-289084844の特定の(new (...) => MyClass) & MyStaticInterfaceを解決します。

答えないでください

同じ理由で、大きな注釈を減らすためにtype宣言を使用することがありますが、 abstract staticのようなキーワードは、既存のものとして言及されているような比較的消化が難しい構成よりもはるかに読みやすいと思います例。

さらに、抽象クラスについてはまだ取り上げていませんか？

私の意見では、抽象クラスを使用しないという解決策は解決策ではありません。 これは回避策です。 何を回避するのですか？

この機能リクエストは、リクエスターを含む多くの人が、インターフェイスにabstract staticやstaticなどの期待される機能が存在しないことに気付いたために存在すると思います。

提供されたソリューションに基づいて、 staticキーワードは、その使用を回避するための回避策がある場合でも存在する必要がありますか？ それを提案するのも同様にばかげていると思います。

ここでの問題は、 staticの方がはるかに理にかなっていることです。
生成された関心に基づいて、私たちはいくつかのより否定的な議論をすることができますか？

この提案に更新はありますか？ 検討する価値のある議論は、なぜstatic abstractなどを持ってはいけないのかを示していますか？
なぜそれが役立つのかを示す提案がもっとありますか？

おそらく、私たちは物事を巻き込み、議論されたことを要約する必要があります。そうすれば、解決策を見つけることができます。

私が理解しているように、2つの提案があります。

1. インターフェイスとタイプは静的プロパティとメソッドを定義できます

interface ISerializable<T> { 
   static fromJson(json: string): T;
}

1. 抽象クラスは抽象静的メソッドを定義できます

abstract class MyClass<T> implements ISerializable<T> {
   abstract static fromJson(json: string): T;
}

class MyOtherClass extends MyClass<any> {
  static fromJson(json: string) {
  // unique implementation
  }
}

提案1については、技術的には回避策があります。 これは素晴らしいことではありませんが、少なくともそれは何かです。 ただし、これは回避策です。

インターフェイスを2つに分割して、次のようにクラスを書き直すことができます。

interface StaticInterface {
  new(...args) => MyClass;
  fromJson(json): MyClass;
}

interface InstanceInterface {
  toJson(): string;
}

const MyClass: StaticInterface = class implements InstanceInterface {
   ...
}

私の意見では、これは多くの余分な作業であり、少し読みにくく、クラスを面白い方法で書き直すという欠点があります。これは単に奇妙で、使用している構文から逸脱しています。

では、提案2についてはどうでしょうか。 それについてできることは何もありませんね。 それも対処する価値があると思います！

これらのタイプの1つの実際の使用法は何ですか？これらの1つはどのように使用されますか？

interface JsonSerializable {
    toJSON(): string;
    static fromJSON(serializedValue: string): JsonSerializable;
}

値は{ fromJSON(serializedValue: string): JsonSerializable; }のようなオブジェクトでなければならないと言うことはすでに可能ですが、これはパターンを強制するためだけに必要ですか？ タイプチェックの観点からは、そのメリットはわかりません。 補足として、この場合、操作が難しいパターンを適用することになります。ここでは説明しませんが、多くの理由から、シリアル化プロセスを個別のシリアライザークラスまたは関数に移動することをお勧めします。

さらに、なぜこのようなことが行われているのですか？

class FirstChildClass extends AbstractParentClass {
    public static getSomeClassDependentValue(): string {
        return 'Some class-dependent value of class FirstChildClass';
    }
}

代わりに、テンプレートメソッドまたは戦略パターンのいずれかを使用するのはどうですか？ それはうまくいき、より柔軟になりますよね？

現時点では、この機能に反対しています。これは、操作が難しいクラス設計を記述するために不必要な複雑さが追加されるように思われるためです。 たぶん、私が見逃しているいくつかの利点がありますか？

静的Reactメソッドの有効なユースケースが1つあります。それについてです。

@ aleksey-bykovああ、わかりました。 そのような場合、 constructorプロパティに型を追加すると、そのまれなシナリオで型チェックが発生する方がよい場合があります。 例えば：

interface Component {
    constructor: ComponentConstructor;
}

interface ComponentConstructor {
    displayName?: string;
}

class MyComponent implements Component {
    static displayName = 5; // error
}

それは私にとってはるかに価値があるようです。 言語に複雑さを追加することはなく、クラスがインターフェイスを適切に実装しているかどうかをチェックするときに、型チェッカーの作業が増えるだけです。

ちなみに、インスタンスからコンストラクターに移動し、最後に型チェックを使用して静的メソッドまたはプロパティに移動する場合が有効なユースケースになると考えていましたが、型にconstructorプロパティを入力することですでに可能です。 ＃3841のクラスインスタンスで解決されます。

私は同様の考えを持っていました： https ：//github.com/Microsoft/TypeScript/issues/14600#issuecomment -437071092

アップスレッドで記述されたシリアル化/逆シリアル化パターンは「有効」ではありませんか？

@dsherretは、「タイプチェックの観点からメリットを確認する」ことはしません。 そもそも静的分析を行うことの全体的なポイントは、エラーをできるだけ早くキャッ​​チすることです。 呼び出しの署名を変更する必要がある場合、それを呼び出すすべての人、または重要なことに、署名を使用するメソッドの実装を担当するすべての人が新しい署名に更新するように入力します。

静的なfoo(x: number, y: boolean, z: string)メソッドを持つ兄弟クラスのセットを提供するライブラリがあり、ユーザーがこれらのクラスのいくつかを取り、メソッドを呼び出してインスタンスを構築するファクトリクラスを作成することが期待されているとします。 （多分それdeserializeまたはcloneまたはunpackまたはloadFromServerです。）ユーザーは同じ（おそらく抽象）親のサブクラスも作成しますライブラリからのクラス。

ここで、最後のパラメーターがオプションオブジェクトになるように、そのコントラクトを変更する必要があります。 3番目の引数に文字列値を渡すことは回復不能なエラーであり、コンパイル時にフラグを立てる必要があります。 fooを呼び出すときに、代わりにオブジェクトを渡すようにファクトリクラスを更新する必要があります。また、 fooを実装するサブクラスは、呼び出しシグネチャを変更する必要があります。

新しいライブラリバージョンに更新するユーザーが、コンパイル時に重大な変更をキャッチすることを保証したいと思います。 ライブラリは、上記の静的インターフェイスの回避策の1つ（ type MyClass = (new (data: number[]) => MyInterface) & MyStaticInterface;など）をエクスポートする必要があり、コンシューマーがそれをすべての適切な場所に適用することを期待します。 実装の1つを装飾するのを忘れた場合、またはライブラリのエクスポートされた型を使用してファクトリクラスのfooの呼び出しシグネチャを記述しなかった場合、コンパイラは何も変更されたとは言えず、ランタイムエラーが発生します。 親クラスにabstract staticメソッドを適切に実装した場合とは対照的に、特別なアノテーションは不要で、コードを消費する負担もありません。そのまま使用できます。

@ thw0rtedほとんどのライブラリはこれらのクラスの何らかの登録を必要とせず、その時点で型チェックを行うことができますか？ 例えば：

// in the library code...
class SomeLibraryContext {
    register(classCtor: Function & { deserialize(serializedString: string): Component; }) {
        // etc...
    }
}

// then in the user's code
class MyComponent extends Comonent {
    static deserialize(serializedString: string) {
        return JSON.parse(serializedString) as Component;
    }
}

const context = new SomeLibraryContext();
// type checking occurs here today. This ensures `MyComponent` has a static deserialize method
context.register(MyComponent);

または、これらのクラスのインスタンスがライブラリで使用されており、静的メソッドを取得するためにライブラリがインスタンスからコンストラクタに移動しますか？ その場合、静的メソッドを必要としないようにライブラリの設計を変更することができます。

ちなみに、インターフェースの実装者として、コンストラクターがないために静的メソッドに依存性を注入するのは非常に難しいため、静的メソッドを作成することを余儀なくされた場合、私は非常にイライラします（ctor依存性は不可能です）。 また、状況に応じて、逆シリアル化の実装を他のものと交換することも困難になります。 たとえば、さまざまなシリアル化メカニズムを使用してさまざまなソースから逆シリアル化していたとします。これで、静的な逆シリアル化メソッドができました。これは、設計上、クラスの実装に対して一方向にしか実装できません。 これを回避するには、クラスに別のグローバル静的プロパティまたはメソッドを設定して、静的逆シリアル化メソッドに何を使用するかを指示する必要があります。 使用するものを簡単に交換でき、（逆）シリアル化を（逆）シリアル化されているクラスに結合しない、別のSerializerインターフェースをお勧めします。

ファクトリパターンを使用するには、最終的に実装クラスをファクトリに渡す必要があり、そのときに静的チェックが実行されます。 ファクトリ準拠のクラスを提供したいが、現時点では実際には使用しない場合もあると思います。その場合、 abstract static制約は問題を早期にキャッチし、意味を明確にします。

私はあなたの「サイドノート」の懸念に反しないと思う別の例があります。 フロントエンドプロジェクトにはいくつかの兄弟クラスがあり、特定の機能に使用する「プロバイダー」をユーザーに選択させることができます。 もちろん、 name => Providerのどこかに辞書を作成し、キーを使用して選択リストに何を表示するかを決定することもできますが、現在実装している方法は、静的なnameフィールドを要求することです。各プロバイダーの実装で。

ある時点で、これをshortNameとlongNameの両方を要求するように変更しました（使用可能な画面スペースの量が異なるさまざまなコンテキストでの表示用）。 選択リストコンポーネントをproviderList: Type<Provider> & { shortName: string } & { longName: string }に変更する代わりに、 abstract static name: string;をabstract static shortName: string;などに変更する方がはるかに簡単でした。 それは、適切な場所（つまり、消費コンポーネントではなく、抽象的な親）で意図を伝え、読みやすく、変更しやすいものです。 回避策があると言えると思いますが、それでも、提案された変更よりも客観的に悪いと思います。

最近、インターフェイスで静的メソッドを使用する必要があるときに、この問題に遭遇しました。 この量のコメントを読む時間がないので、これが以前にすでに対処されている場合は、お詫び申し上げます。

私の現在の問題：TypeScriptプロジェクトで使用したいプライベート.jsライブラリがあります。 そこで、先に進んでそのライブラリの.d.tsファイルを書き始めましたが、ライブラリは静的メソッドを使用しているため、実際にはそれを完了できませんでした。 この場合に提案されるアプローチは何ですか？

回答ありがとうございます。

@greeny https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -449610196

@greenyは実用的なソリューションです： https ：//github.com/Microsoft/TypeScript/issues/14600#issuecomment -437071092

具体的には、この部分：

type MyClass = (new (text: string) => MyInterface) & { myStaticMethod(): string; }

別のユースケース：生成されたコード/部分的なクラスシム

• Swagger仕様を生成する@rsuter / nswagライブラリを使用しています。
• 生成されたファイルにマージされる「extensions」ファイルを作成できます。
• 拡張ファイルは実行されませんが、それ自体でコンパイルする必要があります。
• そのファイル内で、まだ存在していないものを参照する必要がある場合があります（生成されているため）
• したがって、私はそれのためのシム/インターフェースを次のように宣言したいと思います
• 注：特定のimportステートメントが最終的なマージで無視されるように指定して、最終的に生成されたコードで「shim」インクルードが無視されるようにすることができます。

interface SwaggerException
{
    static isSwaggerException(obj: any): obj is SwaggerException;
}

しかし、私はこれを行うことができず、実際にクラスを作成する必要があります。これは問題ありませんが、それでも間違っていると感じます。 他の多くの人が言っているように、「これは契約です」と言いたいだけです。

コード生成について他に言及されていないので、ここにこれを追加したかっただけですが、多くの「なぜこれが必要なのか」というコメントはイライラします。 インターフェースでこの「静的」機能を「必要としている」人々のかなりの割合が、外部のライブラリ項目を参照できるようにするためだけにそれを行っていると思います。

また、私は本当によりクリーンなd.tsファイルを見たいと思っています-この機能とそれらのファイルとの重複が必要です。 JQueryStaticのようなものは、単なるハックのように見えるため、理解するのは困難です。 また、現実には、 d.tsファイルは古く、維持されていないことが多く、自分でシムを宣言する必要があります。

（jQueryについて言及して申し訳ありません）

シリアル化の場合、私はそのようなことをしました。

export abstract class World {

    protected constructor(json?: object) {
        if (json) {
            this.parseJson(json);
        }
    }

    /**
     * Apply data from a plain object to world. For example from a network request.
     * <strong i="6">@param</strong> json Parsed json object
     */
    abstract parseJson(json: object): void;

    /**
     * Parse instance to plane object. For example to send it through network.
     */
    abstract toJson(): object;
}

しかし、それでも次のようなものを使用する方がはるかに簡単です。

export abstract class World {

    /**
     * Create a world from plain object. For example from a network request.
     * <strong i="10">@param</strong> json Parsed json object
     */
    abstract static fromJson(json: object): World;

    /**
     * Parse instance to plane object. For example to send it through network.
     */
    abstract toJson(): object;
}

私はこのスレッドをたくさん赤くしましたが、なぜこのパターンにノーと言うのが良いのか正しいのかまだわかりません。 あなたがその意見を共有するなら、あなたはまた、Javaや他の人気のある言語がそれを間違っていると言います。 または私は間違っていますか？

この号は2年間公開されており、79件のコメントがあります。 Awaiting More Feedbackというラベルが付いています。 決定を下すために必要な他のフィードバックを教えてください。

インターフェイスでも抽象クラスでも静的メソッドを記述できないのは本当に迷惑です（宣言のみ）。 この機能はまだ実装されていないため、回避策を書くのはとても醜いです=（

たとえば、next.jsは、静的なgetInitialProps関数を使用して、ページを作成する前にページのプロパティを取得します。 スローされた場合、ページは作成されませんが、エラーページが作成されます。

https://github.com/zeit/next.js/blob/master/packages/next/README.md#fetching -data-and-component-lifecycle

ただし、残念ながら、このメソッドを実装する手がかりは、型チェックができないため、実行時にエラーが発生した場合でも、任意の型シグネチャを与えることができます。

この問題はここに長い間存在していると思いますが、これはJavaScript自体が静的なものが得意ではないためです🤔

静的継承は、そもそも存在してはなりません。 🤔🤔

静的メソッドを呼び出したり、静的フィールドを読み取ったりしたいのは誰ですか？ 🤔🤔🤔

• 子クラス：静的であってはなりません
• 親クラス：コンストラクター引数を使用
• その他：ISomeClassConstructorインターフェースを使用

他にユースケースはありますか？🤔🤔🤔🤔

これに関する更新はありますか？

それが助けになるなら、クラスの静的インターフェースを入力する必要がある場合に私がしたことは、デコレータを使用してクラスに静的メンバーを強制することです

デコレータは次のように定義されます。

export const statics = <T extends new (...args: Array<unknown>) => void>(): ((c: T) => void) => (_ctor: T): void => {};

静的コンストラクターメンバーインターフェイスが次のように定義されている場合

interface MyStaticType {
  new (urn: string): MyAbstractClass;
  isMember: boolean;
}

Tのメンバーを静的に宣言する必要があるクラスで呼び出されます。

@statics<MyStaticType>()
class MyClassWithStaticMembers extends MyAbstractClass {
  static isMember: boolean = true;
  // ...
}

最も頻繁な例は良いです：

interface JsonSerializable {
    toJSON(): string;
    static fromJSON(serializedValue: string): JsonSerializable;
}

しかし、ここで＃13462で述べたように：

インターフェイスは、オブジェクトが提供する機能を定義する必要があります。 この機能は、オーバーライド可能で交換可能である必要があります（これが、インターフェイスメソッドが仮想である理由です）。 静的メソッドは、動的動作/仮想メソッドと並行する概念です。

TypeScriptのインターフェイスは、オブジェクトインスタンス自体だけを記述し、その使用方法を説明するという点に同意します。 問題は、オブジェクトインスタンスがクラス定義ではなく、 staticシンボルがクラス定義にのみ存在する可能性があることです。

だから私は、そのすべての欠陥とともに、以下を提案するかもしれません：

インターフェイスは、オブジェクトまたはクラスのいずれかを記述できます。 クラスインターフェイスがキーワードclass_interfaceで示されているとしましょう。

class_interface ISerDes {
    serialize(): string;
    static deserialize(str: string): ISerDes
}

クラス（およびクラスインターフェイス）は、 statically implementsキーワードを使用して、オブジェクトインターフェイスを使用して静的シンボルを宣言できます（クラスインターフェイスをstatically実装することはできません）。

クラス（およびクラスインターフェイス）は、オブジェクトインターフェイスまたはクラスインターフェイスでimplementsキーワードを引き続き使用します。

クラスインターフェイスは、静的に実装されたオブジェクトインターフェイスとインスタンス実装されたインターフェイスを組み合わせることができます。 したがって、次のようになります。

interface ISerializable{
    serialize(): string;
}
interface IDeserializable{
    deserialize(str: string): ISerializable
}

class_interface ISerDes implements ISerializable statically implements IDeserializable {}

このように、インターフェースはその意味を維持でき、 class_interfaceはクラス定義専用の新しい種類の抽象化シンボルになります。

重要ではない小さなユースケースがもう1つあります。
Angular for AOTコンパイルでは、デコレータで関数を呼び出すことはできません（ @NgModuleモジュールデコレータのように）
角度の問題

Service Workerモジュールの場合、次のようなものが必要です。
ServiceWorkerModule.register('ngsw-worker.js', {enabled: environment.production})
サブクラスを使用する環境で、実装するデフォルト値と抽象プロパティを使用して抽象クラスを拡張します。 同様の実装例
したがって、クラスの構築は関数であるため、AOTは機能せず、次のようなエラーがスローされます。 Function calls are not supported in decorators but ..

それを機能させ、オートコンプリート/コンパイラのサポートを維持するために、静的レベルで同じプロパティを定義することが可能です。 ただし、「実装する」プロパティには、静的メンバーまたは抽象クラスの抽象静的メンバーとのインターフェースが必要です。 両方ともまだ不可能です。

インターフェイスを使用すると、次のように機能します。

// default.env.ts
interface ImplementThis {
  static propToImplement: boolean;
}

class DefaultEnv {
  public static production: boolean = false;
}

// my.env.ts
class Env extends DefaultEnv implements ImplementThis {
  public static propToImplement: true;
}

export const environment = Env;

抽象静力学では、次のように機能します。

// default.env.ts
export abstract class AbstractDefaultEnv {
  public static production: boolean = false;
  public abstract static propToImplement: boolean;
}
// my.env.ts
class Env extends AbstractDefaultEnv {
  public static propToImplement: true;
}

export const environment = Env;

回避策はありますが、すべて弱いです：/

@DanielRosenwasser @RyanCavanaughは言及をお詫びしますが、この機能の提案は、コミュニティから多くのサポートを受けており、実装はかなり簡単だと思いますが、Issuesカテゴリの奥深くに埋もれているようです。 この機能についてコメントはありますか？PRを歓迎しますか？

この問題は＃1263の重複ではありませんか？ 😛

26398（実装型のコンストラクタープロパティに基づく型チェック静的メンバー）は、より良い解決策のように見えます...このようなものが実装される場合は、それがそれであることを願っています。 これは、追加の構文/解析を必要とせず、単一のシナリオのタイプチェックの変更にすぎません。 また、これほど多くの質問は発生しません。

インターフェイスの静的メソッドは、抽象クラスの静的抽象メソッドほど直感的ではないように感じます。

インターフェイスはクラスではなくオブジェクトを定義する必要があるため、インターフェイスに静的メソッドを追加するのは少し大雑把だと思います。 一方、抽象クラスはサブクラスを定義するために使用されるため、抽象クラスは静的抽象メソッドを持つことを確実に許可する必要があります。 これの実装に関する限り、抽象クラスを拡張するとき（たとえば、 class extends MyAbstractClass ）は、型として使用するとき（たとえば、 let myInstance: MyAbstractClass $）ではなく、単に型チェックする必要があります。

例：

abstract class MyAbstractClass {
  static abstract bar(): number;
}

class Foo extends MyAbstractClass {
  static bar() {
    return 42;
  }
}

今やむを得ずこれを使っています

abstract class MultiWalletInterface {

  static getInstance() {} // can't write a return type MultiWalletInterface

  static deleteInstance() {}

  /**
   * Returns new random  12 words mnemonic seed phrase
   */
  static generateMnemonic(): string {
    return generateMnemonic();
  }
}

これは不便です！

「オブジェクト」にプロパティを追加するときに問題が発生しました。これがサンドボックスの例です。

interface Object {
    getInstanceId: (object: any) => number;
}

Object.getInstanceId = () => 42;
const someObject = {};
Object.getInstanceId(someObject); // correct
someObject.getInstanceId({}); // should raise an error but does not

現在、すべてのオブジェクトインスタンスはプロパティgetInstanceIdを持っていると見なされますが、 Objectだけが持っている必要があります。 静的プロパティがあれば、問題は解決されたはずです。

ObjectではなくObjectConstructorを拡張する必要があります。 実際にコンストラクター自体にメソッドをアタッチする場合は、インスタンスメソッドを宣言します。 これは、宣言のマージによってすでに可能だと思います。

`` `` ts
グローバルを宣言する{
インターフェイスObjectConstructor {
hello（）：文字列;
}
}

Object.hello（）;
`` ``

@ thw0rtedすばらしい！ ObjectConstructorを知らなかったありがとう

より大きなポイントは、インスタンス型ではなくコンストラクタ型を拡張しているということです。 lib.es5.d.tsのObject宣言を調べたところ、タイプがObjectConstructorであることがわかりました。

この問題がまだ残っているとは信じがたいです。 これは合法的に役立つ機能であり、いくつかの実際の使用例があります。

TypeScriptの要点は、コードベースで型の安全性を確保できるようにすることです。それでは、なぜこの機能は2年分のフィードバックの後も「フィードバックを保留」しているのでしょうか。

私はこれについてはかなり遠いかもしれませんが、Pythonのメタクラスが、TypeScriptのパラダイムに違反することなく（つまり、インスタンスとクラス）？

このようなもの：

interface DeserializingClass<T> {
    fromJson(serializedValue: string): T;
}

interface Serializable {
    toJson(): string;
}

class Foo implements Serializable metaclass DeserializingClass<Foo> {
    static fromJson(serializedValue: string): Foo {
        // ...
    }

    toJson(): string {
        // ...
    }
}

// And an example of how this might be used:
function saveObject(Serializable obj): void {
    const serialized: string = obj.toJson();
    writeToDatabase(serialized);
}

function retrieveObject<T metaclass DeserializingClass<T>>(): T {
    const serialized: string = getFromDatabase();
    return T.fromJson(serialized);
}

const foo: Foo = new Foo();
saveObject(foo);

const bar: Foo = retrieveObject<Foo>();

正直なところ、このアプローチの最も難しい部分は、 metaclass ... staticimplements 、 classimplements 、 withstaticの意味のあるTypeScript-yキーワードを思い付くようです。 implementsstatic ...わからない。

これは@GerkinDevの提案に少し似ていますが、別個の種類のインターフェースがありません。 ここでは、インターフェースの概念が1つあり、それらを使用してインスタンスまたはクラスの形状を記述することができます。 実装クラス定義のキーワードは、各インターフェイスをどちら側でチェックするかをコンパイラに指示します。

目的の機能に応じて、＃34516と＃33892でディスカッションを取り上げましょう。