Typescript: 最終クラスをサポート（サブクラス化不可）

プライベートコンストラクタを持つクラスは拡張できません。 代わりにこれを使用することを検討してください。

私が思い出したことから、コンパイラーはコンストラクターのprivateキーワードを気に入らなかったと確信していました。 たぶん私は貼り付けバージョンを使用していません

これは新機能であり、TS 2.0でリリースされますが、 typescript@nextを使用して試すことができます。 詳細については、 https：//github.com/Microsoft/TypeScript/pull/6885を参照してください。

よろしくお願いします

プライベートコンストラクターは、クラスをクラスからインスタンス化できないようにしませんか？ それは最終クラスへの正しい答えではありません。

JavaやC＃は、 finalクラスを使用して、実行時にクラスを最適化します。これは、クラスが特殊化されないことを認識しています。 これが最終的なサポートの主な価値であると私は主張します。 TypeScriptでは、finalを使用しない場合よりもコードを実行しやすくするために提供できるものはありません。
コメントを使用して、クラスの正しい使用法をユーザーに通知するか、最終的なクラスを公開せず、代わりにインターフェースを公開することを検討してください。

私はそれに同意しません、代わりに私はduanyaoに同意します。 コンストラクターを使用して最終的なクラスをインスタンス化できるようにしたいので、Privateはその問題を解決しません。 また、それらをユーザーに公開しないと、追加のファクトリを作成する必要があります。 私にとって、最終サポートの主な価値は、ユーザーがミスを犯さないようにすることです。
そのように主張する：関数シグネチャで型を使用する場合、TypeScriptはコードの実行を高速化するために何を提供しますか？ ユーザーのミスを防ぐためだけではありませんか？ ユーザーがパラメーターとして渡す必要のある値のタイプを説明するコメントを書くことができます。 私の意見では、typescriptの本来の意図と衝突するため、finalキーワードのような拡張機能が押しのけられるのは残念です。コンパイルレベルを追加してJavaScriptをより安全にし、できるだけ多くのチェックを実行して、多くの間違いを回避します。可能な限り前もって。 それとも、TypeScriptの意図を誤解しましたか？

メソッドにはfinal修飾子も必要です。

class Foo {
  final fooIt():void{

  }
}

class Bar {
  fooIt():void {

  }
}
// => Method fooIt of Bar cannot override fooIt of Foo, because it is final.

たとえば、fooItがオーバーライドされるのを緊急に回避したい場合は、次のパターンをよく使用します。

import Whatever ...

abstract class Foo {
  private ImportantVariable:boolean;

  protected abstract fooIt_inner:Whatever();

  public final fooIt():Whatever() {
    //do somestate change to aprivate member here, which is very crucial for the functionality of every Foo:
    ImportantVariable = true;
    //call the abstract inner functionality:
    return this.fooIt_inner();    
  }
}

コスト対効用についての議論はかなり主観的なものです。 主な懸念事項は、すべての新機能、構成、またはキーワードが言語とコンパイラ/ツールの実装を複雑にすることです。 言語設計会議で私たちがやろうとしていることは、トレードオフを理解し、付加価値が導入された複雑さを重視する場合にのみ、新しい機能を追加することです。

コミュニティのメンバーがフィードバックを追加し続けることができるように、問題はロックされていません。 十分なフィードバックと説得力のあるユースケースがあれば、問題を再開できます。

実際、finalは非常に単純な概念であり、言語に複雑さを加えることはないため、追加する必要があります。 少なくともメソッドについては。 多くの人が大きなプロジェクトに取り組んでいるとき、誰かがメソッドをオーバーライドできないようにすることは価値があります。それはオーバーライドされるべきではありません。

TypeScriptでは、finalを使用しない場合よりもコードを実行しやすくするために提供できるものはありません。

うわー、クリンジ！ 静的型もコードの実行を改善するものではありませんが、安全性は良いことです。

クラスのカスタマイズを少し安全にするために私が見たい機能として、Final（sealed）がオーバーライドされています。 パフォーマンスは気にしません。

静的型もコードの実行を改善するものではありませんが、安全性は良いことです。

丁度。 privateが他の人がメソッドを呼び出さないようにするのと同じように、 finalは他の人がメソッドをオーバーライドするのを制限します。

どちらも、クラスの外界とのOOインターフェースの一部です。

@pauldraperと@mindarelusに完全に同意します。 これを実装してください、これは私が現在本当にそれを逃していることは非常に理にかなっています。

finalはパフォーマンスだけに役立つとは思いません。デザインにも役立つと思いますが、TypeScriptではまったく意味がないと思います。 これは、 Object.freezeとObject.sealの可変性の影響を追跡することでよりよく解決されると思います。

@aluanhaddadそれをもっと詳しく説明できますか？ なぜ「TypeScriptではまったく意味がない」と思いますか？
オブジェクトのフリーズまたはシールとは、オブジェクトへの新しいプロパティの追加を禁止することを意味しますが、派生オブジェクトへのプロパティの追加を妨げることはありません。したがって、基本クラスをシールする場合でも、その基本クラスを拡張する子クラスのメソッドをオーバーライドできます。 。 さらに、実行時に基本クラスにプロパティを追加できませんでした。

Javaのクラスまたはクラスメソッドでfinalを使用するという考えは、私の意見では、スレッドセーフのためにオブジェクトの可変性を最小限に抑えることと関係があります。 （アイテム15. Joshua Bloch、効果的なJava）

JSのすべてが変更可能であるため、これらのプリンシパルがjavascriptに引き継がれるかどうかはわかりません（間違っている場合は修正してください）。 しかし、TypescriptはJavascriptではありませんね。

私はこれが実装されることを本当に望んでいます。 より堅牢なコードを作成するのに役立つと思います。 さて...それがJSにどのように変換されるか、正直なところ、おそらくそうする必要はありません。 コンパイル時の残りのチェックが行われるフェンスのタイプスクリプト側にとどまることができます。

確かに私はそれなしで生きることができます、しかしそれはタイプスクリプトが何であるかの一部ですよね？ 見落とした間違いを再確認しますか？

私にとって、 finalは、タイプスクリプトでprivateまたはタイピングと同じ役割を果たします。つまり、コードコントラクトです。 これらは、コードコントラクトが壊れないようにするために使用できます。 とても欲しいです。

@ hk0iは、ここにエコーされているのと同様の方法で、アイテム17（第2版）にも記載されています。

しかし、通常の具象クラスはどうですか？ 伝統的に、それらは最終的なものでも、サブクラス化のために設計および文書化されたものでもありませんが、この状況は危険です。 このようなクラスに変更が加えられるたびに、クラスを拡張するクライアントクラスが破損する可能性があります。 これは単なる理論上の問題ではありません。 継承用に設計および文書化されていない非最終的な具象クラスの内部を変更した後、サブクラス化関連のバグレポートを受け取ることは珍しくありません。

この問題の最善の解決策は、安全にサブクラス化されるように設計および文書化されていないクラスでのサブクラス化を禁止することです。 サブクラス化を禁止する方法は2つあります。 2つのうち簡単なのは、クラスをfinalと宣言することです。 別の方法は、すべてのコンストラクターをプライベートまたはパッケージプライベートにし、コンストラクターの代わりにパブリック静的ファクトリを追加することです。

抽象キーワードがすでに存在することを考えると、言語の認知の複雑さを増すことはないと私は主張します。 しかし、私はそれの実装/パフォーマンスへの影響について話すことはできず、その角度から言語を保護することを絶対に尊重します。 これらの懸念を分離することは、この機能を実装するかどうかを決定する上で有益だと思います。

finalは、クラスを封印するための優れた追加になると思います。 ユースケースの1つは、クラスに多数のパブリックメソッドがあるが、インターフェイスを介してそれらのサブセットのみを公開する場合です。 実際のコンシューマーがインターフェースを使用してそれらへのアクセスを制限している間、実装にはこれらすべてのパブリックメソッドがあるため、実装をすばやく単体テストできます。 実装を封印できることで、誰も実装を拡張したり、パブリックメソッドを変更したりすることがなくなります。

また、誰もあなたのクラスを継承していないことを確認することもできます。 TypeScriptはこれらのルールを適用するために存在する必要があり、コメントに関する提案は、このユースケースを解決するための怠惰なアプローチのようです。 私が読んだもう1つの答えは、特定の状況にのみ適しているが、上記で説明したものには適していないプライベートの使用に関するものです。

このスレッドの多くの人々のように、私はクラスを封印できるように投票します。

@mhegazyプライベートコンストラクターとsealed / finalクラスは、セマンティクスが大きく異なります。 もちろん、プライベートコンストラクターを定義することで拡張を防ぐことはできますが、クラスの外部からコンストラクターを呼び出すこともできません。つまり、インスタンスを作成できるように静的関数を定義する必要があります。

個人的には、sealed / finalとマークされたクラスとメソッドが拡張またはオーバーライドできないことを確認するために、sealed / finalコンパイラチェックを行うことをお勧めします。

私の問題のコンテキストでは、オブジェクトをインスタンス化できるようにパブリックコンストラクターを使用できるようにしたいのですが、クラスの拡張を防ぎ、sealed / finalの追加のみがそれを許可します。

タスクがあります-次のようなコードを記述します

• 不変オブジェクトを操作します
• 相続は無料です
• 無料の反射方法

そして、ここではfinalキーワードが必要です、私見。

finalは、自分自身とユーザーに、オーバーライドする必要のある保護されたメソッドと、オーバーライドしてはならない保護されたメソッドを思い出させるための優れた方法だと思います。 補足として、私はまた、部分的には読者が知っているように、またメソッドの名前をタイプミスするとトランスパイラーが文句を言うように、あなたがオーバーライドしていることを明示的に述べることを支持しています。

@zigszigsdkメソッドがオーバーライドされることはないので、これはどのように機能しますか？

final ：
thisコンテキストからスーパーのメソッド（finalと宣言されている）を非表示にすると、トランスパイラーが文句を言うことを除いて、現在と同じように機能します。

override ：
現在と同じように機能しますが、トランスパイラーがメソッドoverride宣言し、そのスーパーにその名前のメソッドがないか、メソッドはあるがfinalと宣言されている場合に文句を言う点が異なります。
スーパーのメソッドをthisコンテキストから非表示にし、状態のオーバーライドを行わない場合は、警告が表示される可能性もあります。

JavaやC＃は、最終クラスを使用して実行時にクラスを最適化します。これは、クラスが特殊化されないことを認識しています。 これが最終的なサポートの主な価値であると私は主張します。

@mhegazyそうではありません！ もう1つの重要な機能は、クラスのどの部分がオーバーライドされると予想されるかを明示することです。

たとえば、「有効なJava」の項目17を参照してください：「継承のために設計および文書化するか、継承を禁止する」：

継承用に設計および文書化されていない非最終的な具象クラスの内部を変更した後、サブクラス化関連のバグレポートを受け取ることは珍しくありません。 この問題の最善の解決策は、安全にサブクラス化されるように設計および文書化されていないクラスでのサブクラス化を禁止することです。 サブクラス化を禁止する方法は2つあります。 2つのうち簡単なのは、クラスをfinalと

私の意見では、最終的な方法についても同じことが言えます。 これは、クラスがそのパブリックメソッドのいずれかをオーバーライドサポートするように設計されていることは非常にまれです。 これには、非常に複雑な設計と膨大な量のテストが必要になります。これは、オーバーライドされない動作とオーバーライドされる動作の組み合わせから生じる可能性のある状態のすべての可能な組み合わせを考える必要があるためです。 したがって、代わりに、プログラマーは1つまたは2つを除くすべてのパブリックメソッドをfinalと宣言する可能性があります。これにより、そのような組み合わせの数が大幅に減少します。 そして、多くの場合、1つまたは2つのオーバーライド可能なメソッドがまさに必要なものです。

finalクラスとメソッドは非常に重要だと思います。 実装していただければ幸いです。

もう1つの説得力のあるユーザーケース@mhegazy 。 今日、私はテンプレートメソッドパターンを学び、ウィキペディアのテンプレートメソッドパターンが言うように、サブクラスがテンプレートメソッドを変更することを禁止するためにfinalが必要であることがわかりました。 しかし、私の素敵なTypeScriptではこれを行うことはできません。 お気の毒に！

テンプレートパターンを使用すると、サブクラスは、アルゴリズムの構造を変更せずに、アルゴリズムの特定のステップを再定義できます。

私にとっては、継承よりもケースで構成を強制しようとするのと同じくらい簡単です。 ファイナルなしではこれを行うことはできません。

finalがtypescriptに来ることも望んでいますが、Microsoftが送ろうとしている根本的なメッセージは、 finalが必要な場合は、次のような言語を使用する必要があるということだと思います。それをサポートします。

この問題が再開され、実装されることを望んでいます。

内部で使用したり、（npmなどで）公開で共有したりするライブラリを構築する場合、そのライブラリを使用するユーザーがコードを参照し、コメントやドキュメントを検索して、クラスができるかどうかを確認する必要はありません。上書きされません。 それらが上書きすると、エラーがスローされます。

私のコードには、拡張されるクラスがあり、ある種のイベントが発生すると、メソッドがトリガーされます。 サブクラスがメソッドを定義している場合はそのメソッドになり、そうでない場合はデフォルトのメソッドにフォールバックします。 ただし、クラスには「フォールバック」メソッドではない他のメソッドもあります。これらは、DOMにアイテムを追加するなどのヘルパーメソッドであり、この場合、これらのメソッドが上書きされないようにします。

このトピックに関する私の5セントは、これを再度開いて実装する必要があるということです。

私はそれを使用して、ライブラリのクライアントに独自の具象クラスを作成させ、既存の他のクラスから拡張しないようにします。 @lucasyvasが言ったように、作曲を支持します。 または、新しい具象クラスの実装を強制して、たとえば角度で依存性注入を提供します。

クラスとメソッドの両方をサポートして、再開することにも投票します

typescriptのコンテキストでfinalキーワードのパターンがどのように機能するかわからないだけではいけないと言っているのではありませんか？

最後のキーワードは、ユーザー/プログラマーが上記のクラス/メソッドをオーバーライド/継承するのを止めませんか？

Finalを使用する私の方法は、データを「フリーズ」することです。つまり、データを変更することはできなくなります。 つまり、これを使用すると便利な場合がありますが、動作を「バグ」修正または変更したい人にとっては本当に面倒な場合があります。

@niokasgami Freezeは[データ]に関連しています（https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/Object/freeze）
ES6の一部としてすでに利用可能です。 Finalはクラスとメソッドに適用されます（変数は読み取り専用である可能性があるため、スーパー変数をオーバーライドできないため、「final」として機能します）。

「Final」キーワードは、 SealedがC＃であるJAVAで使用されます。

タイプスクリプトはC＃に強く影響を受けているため、「封印された」ものが選択される可能性が高くなります。 さて、基本的に実行時にオブジェクトをシールするES6シールと混同する可能性がありますか？

@XampleJavaのローカル変数でfinalを使用することもできると思います。 私はAndroidアプリを書いていたときにそれをしなければならなかったことを覚えています。 イベントでやる必要があったと思いますが、100％確実ではありません。

function(){
    let final myVariable = 'Awesome!'
    document.addEventListener('scroll', e => {
        console.log(myVariable)
        myVariable = 'Not Awesome' // Throws an error
    })
}

@TheColorRedええと、Javaの最後のローカル変数は定数を意味しますね。

@EternalPhaneそうだと思いますが、私は常にconstをグローバルのようなスコープで使用してきました...関数やメソッド内で使用することを考えたことはありません...前のコメントは無効だと思います...

@Xampleええ、C＃からの封印のポイントは同じようには機能していません正直なところ、キーワード封印とファイナルの両方が混乱する可能性があるため（封印などのために封印されている）、ファイナルは実際にはカテゴリに入ることができませんでした。 Javaでは定数として使用されるため、適用方法：/

Javaでは、任意の変数、メソッド、またはクラスをfinalできます。 変数の場合、参照を再割り当てできないことを意味します（非参照タイプの場合、これは値も変更できないことを意味します）。 クラスの場合、拡張機能がないことを意味します（ extends ...キーワード）。 メソッドの場合、サブクラスでオーバーライドしないことを意味します。

Javaでfinalを使用する主な理由：

• 変数の不変性を減らす：スレッドセーフのために
• 継承できないようにクラスをファイナライズします。サブクラスが誤ってスーパーメソッドを呼び出し始めた場合、継承は本質的に複雑であるため、継承よりも構成を強制します。
• 単純なプログラミングエラーを防ぎます：値を変更するつもりがない場合、それはもはや不可能です。
• ほとんどの人が定数を想像するときに考えるものに使用されます。 public static final String KEY = "someStringKeyPathHere"ようにどこにでも表示される再利用可能な値は、間違いを減らすのに役立ちますが、同じ値に対して複数の文字列オブジェクトを再作成しないというコンパイル時の利点があります。

私はいくつかのユースケースを省略したかもしれませんが、私はそれを非常に一般的に保ち、いくつかの例を挙げようとしていました。

@TheColorRed Androidは、コールバック（匿名クラス）の外部で変数を宣言し、内部でそれを参照するときにそれを必要とします。 これはスレッドセーフの問題とも一致すると思います。 彼らはあなたが別のスレッドから変数を再割り当てするのを阻止しようとしていると思います。

その有用性にもかかわらず、私はこの機能がすぐに来るとは思わない。 他の解決策を検討するか、私の場合のように、typescriptをまとめて削除し、JSの不備に対処するのに良い時期かもしれません。 Javascriptには、このタイプのヒントなどがないことで多くの「利点」があり、最終的にはコードがJSに変換されます。 ブラウザの互換性が必要な場合は、ES6を作成し、Babelを使用して変換できます。

これらの利点のいくつかを手首に叩くことができたとしても、jsに変換されると、Java風のfinalの本当の利点は得られないと現実的に思います。

@ hk0i私はあなたの意見を理解できたと思いますが、全体的に私はあなたの意見について同時に賛成し、ちょっと反対します。

タイプスクリプトのコードのほとんどは、プログラマーが「クリーン」なコードを実行できるようにするためのデバッグ/追跡の目的であると言えます（ここにタイプスクリプトのスパゲッティコードがあることを知っているので、引用しないでください）

ほとんどのtypescript機能は、JSに存在しないため、JSに変換してもほとんどの場合トランスパイルされません。

ランタイム/コードを書くときは、コードのエラーを確認し、JSよりも簡単に追跡するのに役立ちます（そしてHECK JSはバグを追跡するのが難しい場合があります笑）

したがって、finalキーワードの使用は、APIユーザーが知るためのブロッカーとして機能している可能性があると思います。拡張機能は奇妙な動作などを引き起こす可能性があるため、このクラスを拡張しないでください...

良い言語としてのTypescriptは、人々がクラスコンストラクターを呼び出さないようにするが、それでもアクセスできる「真の」静的クラスキーワードなどの重要な機能が欠けていることに気付くのは悲しいことです。

@ hk0iどちらにも同意しません

ランタイム可変性チェックを追加する現在のES6ソリューションに依存すると（Object.sealまたはObject.freezeを使用するなど）、コードを入力するときに直接エラーが発生するという利点が失われます（このデコレータを使用すると簡単に実行できますが）。

@TheColorRedはい…そしてtypescriptでは、ローカル変数とクラス変数を区別しています。

• クラス変数の場合はreadonly
• const ：その他の変数の場合

それらのどれもメソッドまたはクラスに対して正確ではありません。 メソッドをオーバーライドすることは、それを再定義することを意味しません（C ++の仮想メソッドを考えてください）。スーパーメソッド（ superを使用して呼び出すことができます）の前にメソッドがプライマリで呼び出されることを定義するだけです。

@niokasgamiおそらく、

TL; DR：

• PreventExtensionsは、クラスの拡張を防ぐための適切な明示的な名前です。
• PreventOverridesは、クラスのオーバーライドを防ぐための適切な候補名になります
  sealはC＃で広く使用されており、短く、予想される動作は同じです。

ちなみにObject.preventExtensions()もあると言うのを忘れました
違いはここでます

読む

• 常に可能…書き込み専用変数が必要なのは誰ですか？

更新と削除

• 変数の削除を再定義しないようにする：クラスメンバーの場合は読み取り専用、const（その他の場合）
• メソッドの再定義を防ぐ：（クラスメソッド内で） this.aMethod = ()=>{}を行うことを妨げるものは何もありません。 このようなハッキングを防ぐために、メソッドもreadonlyにする必要がありますか？ delete this.aMethodについても同じ

作成

• オブジェクトにのみ適用されるか、ここで構造について説明しているように： classクラスがオブジェクトのメンバーを定義しているため、typescriptは暗黙的に新しいプロパティをその場で作成することをすでに禁止しています...たとえばthis.unKnownProperty = "something" ts予想どおり、コンパイル時エラーTS2339が発生します。

延長

• クラスにのみ適用され、オブジェクト自体にはまだ何もしていません…（実行時の作成とは異なります）。 これは、 finalまたはsealが関連する場所です。 問題は、ES6のフリーズ、シール、およびpreventExtensionsで一貫性を保つ方法です。 （必要な場合）。
  クラスを拡張するとは、このクラスから別のクラスを作成できないようにすることを意味します。 その後、それを読み取ることはできますが、削除することはできません（とにかくクラスを削除します）。 問題は「更新」列ではありません。 finalクラスは更新可能ですか？ 更新可能なクラスとは何ですか？ 私の推測はイエスです…しかし、更新はこのクラスを実装することです（クラスのインターフェースを理解します）？ 別のクラスの実装は常に可能であるはずです…しかし、それは最初のクラスの更新とは関係ありません。 ええと…たぶん彼らはc＃を書いているのと同じ質問に来て、 sealが良いキーワードであると決めました。

オーバーライド

• 拡張クラスで現在のメソッドをオーバーライドしないようにします。 繰り返しますが、定義（クラス内のメソッド）について話しているので、まだ何も上書きしていません。 したがって、作成を禁止し、読み取りを許可し、更新を許可します（メソッドにも適用できる場合は、メソッドの更新または読み取り専用を使用した削除を防止できます）。 最高のネーミング？ preventOverrides ？ または、C＃で使用されているseal

ボーナス：メソッドの封印は通常、必須のスーパーコードを上書きすることを防ぐためのものであるため、スーパーメソッド（コンストラクターと同じ動作ですが、どのメソッドでも）強制することを提案しました。役に立つと思います。

誤解しないでください、私はこれに反対していません。 とても気に入っています。 私は、なぜそれが機能であってはならないのかというマイクロソフトの逆説的な考え方を覆そうとしているだけです。つまり、JavaScript機能ではないため、TypeScript機能にはできないということです。

...私が正しく理解している場合。

@ hk0iジェネリックス、読み取り専用、およびその他の多くの機能はJavaScript機能ではありませんが、TypeScriptに追加されているため、それが理由ではないと思います...

TypeScriptは、単純ではない方法でコードを生成する必要がある機能を避けます。 ジェネリックス、読み取り専用などは純粋にコンパイル時の概念であり、単純に消去して生成された出力を生成できるため、公正なゲームです。

finalはコンパイル時にも「消去」できるのに、なぜそれが「公正なゲーム」にならないのでしょうか。

🤷‍♂️

@TheColorRedこれは多かれ少なかれ、統合する他の優先順位があると思います。
または、この新しいキーワードがコンパイル/コーディング時間でどの程度予測可能であるかがわかりません。 あなたがそれについて考えるならば、最終的なキーワードのデザインは非常に曖昧になる可能性があります。 ファイナルは多くの目的に使用できます。 Jsdocのドキュメントからわかるように、タグ「@final」を使用して、この変数がフリーズされているため読み取り専用であることをjsdocインタープリターに通知できます。

ここでデザインの衝突。 変数を「フリーズ」して読み取り専用にし、finalにすると、変数とgetterに読み取り専用を適用できるため、読み取り専用にもなります。

これは、変数にfinalまたはreadonlyのどちらのタグを付ける必要があるのか​​わからないプログラマーに混乱を引き起こす可能性があります。

このキーワードをクラス宣言とメソッド宣言専用に予約しない限り、動作またはfinalは読み取り専用と衝突すると思います。

封印（object.sealと衝突する可能性がある）またはfinal（この目的の設計は読み取り専用キーワードと衝突する）の代わりに、より「直接的な」方法で名前を付けて設計することができると思います。

これは、C＃の動作と似ているが、同時に異なる動作の「アイデア」にすぎないことに注意してください。 私はC＃が通常どのようにオーバーライド不可能であるかからいくつかのインスピレーションを得ました、そしてあなたはこの方法が仮想であると言わなければなりません。

`名前空間の例{

export class myClass {

    constructor(){}

    // Make the func non ovveridable by inheritance. 
    public unoveridable myMethod(){

    }

    public myMethodB(){

    }
}

export class MyClassB extends myClass {

    // Nope not working will throw an error of an nonOverridable error
    myMethod(){
        super.myMethod();
    }

    // Nope will not work since unoverridable.
    myMethod(){

    }

    // Design could be implemented differently since this could complicate  ¸
    // the pattern of typescript
    public forceoverride myMethod(){
      // destroy previous pattern and ignore the parent method thus a true ovveride
    }

    // Yup will work since it's still "virtual".
    myMethodB(){
        super.myMethodB();
    }
}
// Can extend an existing Parent class
// Declaring an unextendable class make all is component / func nonOverridable by 
// inheritance. (A class component can still be overwritten by prototype usage.)
export unextendable class MyFinalClass extends Parent {

    constructor()

    // nonoverridable by default.
    public MyMethod(){

    }
}
// nope throw error that MyFinalClass is locked and cannot be extended
export class MyChildClass extends MyFinalClass{}

} `

編集：読み取り専用がすでに存在するため、変数を含めずに取得しました。

@mhegazyこの問題を再開することを検討してください。 コミュニティの反応は、Java（ final ）、C＃（ sealed 、 readonly ）、PHPのようなfinalキーワードを追加する側で圧倒的に多いようです。 （ final ）、Scala（ final 、 sealed ）、およびC ++（ final 、 virtual ）があります。 この機能を持たない静的に型付けされたOOP言語を考えることはできません。また、TSがそれを必要としない理由について説得力のある議論を聞いたことがありません。

@ bcherny @ mhegazy私は上記に完全に同意します。 TypeScriptで見られるほとんどのシンタックスシュガーのように、 finalが単なるコンパイル時の制約になり得ないというよく議論されている理由はわかりません-それに直面しましょう、静的型付け、ジェネリックス、アクセス修飾子、型エイリアス、インターフェイス... ALL SUGAR！ TypeScriptチームはおそらく他の方向に言語を取り入れることに集中したいと思うでしょうが、真剣に、これはOOP 101です...これはTypeScriptがまだ非常に若い頃だったはずです！

@mhegazyこの問題についてあなたが行った初期のコメントを

プライベートコンストラクタを持つクラスは拡張できません。 代わりにこれを使用することを検討してください。

これを書いている時点で、このコメントは21回反対票を投じられています。
明らかに、これはコミュニティが解決策として望んでいることではあり

うわー、これについてたくさんのフィードバックを得ました。 なぜ実装することに興味がないのか理解できません

ここで起こっている本当に非生産的な不満がたくさんあります。 ただ声の欲求不満に現れないでください-私たちはここで決定を下すことができ、コミュニティは彼らのフィードバックを与えることができますが、ただ怠惰な歯ぎしりは誰の心も変えることはありません。 具体的かつ実用的であるようにしてください。 我々は今、この機能をDOと言って現れて人々に納得させるつもりはありません。

この問題は最終/封印されたクラスに関するものであることに注意してください。 まったく異なる概念である最終/封印された方法についてのトピック外の議論がありました。

前回レビューした際にいくつかの点が考慮されました

• クラスはJAVASCRIPT機能であり、TYPESCRIPT機能ではありません。 finalないとクラスがまったく役に立たないと本当に感じた場合、それはTC39委員会で取り上げるか、es-discussに持ち込むものです。 finalが必須の機能であることをTC39に納得させようとしない、または納得させることができない場合は、TypeScriptに追加することを検討できます。
• 何かに対してnewを呼び出すことが合法である場合、それはそれから継承することと1対1のランタイム対応を持っています。 new 'dであるが、 super ' dではないものの概念はJavaScriptには存在しません
• TypeScriptがOOPキーワードスープにならないように最善を尽くしています。 JavaScriptの継承よりも優れた構成メカニズムが多数あり、C＃とJavaが持つすべてのキーワードを用意する必要は
• ランタイムチェックを簡単に記述して、「最終的な」クラスからの継承を検出できます。これは、すべてのコンシューマーがTypeScriptを使用しているとは限らないため、誰かが誤ってクラスから継承することを「心配」している場合は、とにかく実行する必要があります。 。
• lintルールを記述して、特定のクラスが継承されないスタイルの規則を適用できます。
• 誰かがあなたの封印されるべきクラスから「偶然に」継承するというシナリオは、一種の奇妙なものです。 また、特定のクラスから継承することが「可能」であるかどうかについての誰かの個別の評価は、おそらくかなり疑わしいと思います。
• クラスを封印する理由は基本的に3つあります。セキュリティ、パフォーマンス、意図です。 これらのうちの2つは、TypeScriptでは意味がないため、他のランタイムで実行するジョブの3分の1しか実行しないものの複雑さとゲインを考慮する必要があります。

これらすべてに異議を唱えることは自由ですが、 finalの欠如がJavaScriptクラスを効果的に使用する能力にどのように悪影響を及ぼしているかについて、実用的で具体的なフィードバックを提供してください。

TSがそれを必要としない理由についての説得力のある議論を聞いたことがありません

これはそれがどのように機能するかではないことを思い出してください。 すべての機能は-100から始まります。 その投稿から

それらの質問のいくつかでは、質問は、なぜ特定の機能を「削除」または「除外」したのかを尋ねます。 この言い回しは、既存の言語（ここでは、C ++とJavaが一般的な選択肢です）から始めて、好きなところまで機能を削除し始めたことを意味します。 そして、信じがたい人もいるかもしれませんが、それは言語が設計された方法ではありません。

複雑さの予算には限りがあります。 私たちが行うすべてのことは、私たちが行う次のすべてのことを0.1％遅くします。 機能をリクエストすると、他のすべての機能が少し難しくなり、少し遅くなり、可能性が少し低くなるように要求します。 Javaがそれを持っているか、C＃がそれを持っているか、それがほんの数行のコードであるか、コマンドラインスイッチを追加できるため、ここでは何も入りません。 機能は、それ自体と将来の負担全体に対して支払う必要があります。

@RyanCavanaugh決定に同意するかどうかはいただきありがとうございます。 言語をスリムに保ちたいと思います。他の人気のある言語が持っている機能が本当に価値があるのか​​、それとも単に一般的なのかを考えるのは良いことです。

@RyanCavanaugh

ここでのポイントは、このフォーラムでは「JavaScriptクラスを効果的に使用する」ということではないと思います。

申し訳ありませんが、私は抵抗できず、「ここで起こっている非生産的な不満」に追加するだけです。最後のキーワードは、説明されたすべての理由、詳細、および他の人の議論に役立ちます。

TypeScriptがOOPキーワードスープにならないように最善を尽くしています。 JavaScriptの継承よりも優れた構成メカニズムがたくさんあります...

finalを使用して、継承よりも合成を強制する場合のように（ここにtypescript言語名ではなく挿入してください）😈
（申し訳ありませんが、抵抗できませんでした）

しかし、もっと重要なことは、TSは、いくつかの追加の型チェックを追加することを除いて、「今日のJavaScriptnow」またはその効果のための何か（la Babel）を導入するための互換性レイヤーになることを主に意図しているようです。

これを実装するための反論の要点は、別の言語の機能が必要な場合は、代わりに他の言語を使用することだと思います。 JavaScriptが必要な場合は、JavaScriptを使用してください。 TypeScriptが必要な場合は、それを使用してください。

KotlinはJSにコンパイルでき、ここの人々が楽しめると思う機能がたくさんあるので、調べるのに役立つかもしれません。 私はそれが依存関係としていくつかのJSライブラリを追加すると思います（私はそれを自分で試していません）。

主なポイントは、TypeScriptに満足できない場合は、使用しないことです。

@RyanCavanaugh

あなたが上で提起した点について...

クラスはJAVASCRIPT機能であり、TYPESCRIPT機能ではありません。 finalないとクラスがまったく役に立たないと本当に感じた場合、それはTC39委員会で取り上げるか、es-discussに持ち込むものです。 finalが必須の機能であることをTC39に納得させようとしない、または納得させることができない場合は、TypeScriptに追加することを検討できます。

私は0.7からTypeScriptをフォローしていて、当時はIIRCがES3-ES5をターゲットにしていました。 当時、クラスは間違いなくTypeScriptの機能でした。 同じ議論がデコレータにも当てはまります-それらはESのカードにありますが、実験的な機能としてすでにTypeScriptにあります。

コミュニティとして、TypeScriptコンパイラがfinalのJavaScriptクラスを何らかの形で発行する必要があると主張しているわけではありません。 アクセス修飾子のコンパイル時チェックで十分であるのと同じように、コンパイル時チェックで十分です。 結局のところ、これらもJavaScriptの機能ではありませんが、TypeScriptはそれでも可能にします。

finalがES機能になった場合、おそらくES *をターゲットにするときにエミッターのそのビットをリファクタリングして、 final適切に出力することができます（クラスが導入されたときと同じように） ES6で）？

何かに対してnewを呼び出すことが合法である場合、それはそれから継承することと1対1のランタイム対応を持っています。 new 'dであるが、 super ' dではないものの概念はJavaScriptには存在しません

繰り返しになりますが、コミュニティは、実行時にfinalを強制するために、ここで何かを魔法のようにすることを期待しているとは思いません。 あなたが正確に述べたように、それは「JavaScriptには存在しません」が、前述のように、コンパイル時の制約で十分です。

TypeScriptがOOPキーワードスープにならないように最善を尽くしています。 JavaScriptの継承よりも優れた構成メカニズムが多数あり、C＃とJavaが持つすべてのキーワードを用意する必要は

これは、ソフトウェア開発コミュニティ全体でかなりよく知られているフレーズです。「継承よりも構成を優先する」ですが、「優先」は、継承を包括的なステートメントとしてはありません。 確かに、C＃とJavaが持つすべてのキーワードが必要というわけではありませんが、 abstractクラス（ちなみに「JavaScriptには存在しない」）を許可する理由があったに違いありません。 finalクラス？

ランタイムチェックを簡単に記述して、「最終的な」クラスからの継承を検出できます。これは、すべてのコンシューマーがTypeScriptを使用しているとは限らないため、誰かが誤ってクラスから継承することを「心配」している場合は、とにかく実行する必要があります。 。

C＃とJavaについても同じことが言えますが、コンパイラレベルで実行するためのsealedとfinalがあるため、ランタイムチェックは必要ありません。

すべてのコンシューマーがTypeScriptを使用しているわけではない場合、 finalクラスから継承するだけでなく、もっと心配する必要があります。 たとえば、 privateまたはprotectedメンバーへのアクセス、静的型チェックなし、またはabstractクラスを構築する機能などです。

TypeScript以外のコンシューマーが可能な限り安全であることを確認するために、コードにこれらすべてのランタイムチェックを実際に散らかす必要がありますか（追加することさえできないものもあります）。

lintルールを記述して、特定のクラスが継承されないスタイルの規則を適用できます。

これは、コードを消費している人がリンターを実行していることを意味するため、それでも実際には適切な解決策ではありません。 これは回避策です。

誰かがあなたの封印されるべきクラスから「偶然に」継承するというシナリオは、一種の奇妙なものです。 また、特定のクラスから継承することが「可能」であるかどうかについての誰かの個別の評価は、おそらくかなり疑わしいと思います。

優れた/優れた開発者は、クラスの拡張など、何かを行う理由について考えます。 それよりも少ないと、理由を本当に理解せずに、「しかしそれは機能する」という精神になってしまいます。

canで始まる質問をするshouldで始まる質問よりも明確な答えを得る傾向があります。

クラスを封印する理由は基本的に3つあります。セキュリティ、パフォーマンス、意図です。 これらのうちの2つは、TypeScriptでは意味がないため、他のランタイムで実行するジョブの3分の1しか実行しないものの複雑さとゲインを考慮する必要があります。

TypeScriptは、セキュリティとインテントの2つの理由を実際に満たすと思いますが、これが純粋にコンパイル時のチェックとして実装された場合、正しく指摘されているように、コンパイラレベルでしか実行でき

finalがないことが、JavaScriptクラスを効果的に使用する能力を損なうことはないと思います。また、JavaScriptクラスがないと使用できなくなることもありません。 finalは、「必要な」機能というよりも「持っておくと便利」な機能の方が多いと思いますが、TypeScriptの多くの機能についても同じことが言えます。

ここでの主な不満は、TypeScriptではabstractクラスと_open_クラスを作成できることですが、継承とポリモーフィズムの観点からは、エレガントで表現力豊かな方法で全体像を描くことはできません。

コンストラクターを非表示にすることは、コミュニティが望んでいることではありません。これは、クラスの実装からセマンティックで表現力のある値を奪うためです。また、アクセス修飾子は「必要なもの」であるため、実行時に強制することもできません。 基本的に「JavaScriptには存在しない」状況です。

開発者として、私には多くの帽子があります。 現在、C＃ハット、Kotlinハット、TypeScriptハットがあります。

• Kotlinの帽子をかぶっていれば、クラスはデフォルトで最終版であるため、 finalについて心配する必要はありません。
• 上の私のC＃の帽子で、私は適用sealed 、私はむしろ、私がすべき尋ねるよりも尋ねるために私の消費者をすることができます強制的に、習慣の問題として。 多くの場合、C＃クラスは実際にはsealedである必要があり、見過ごされがちです。
• TypeScriptの帽子をかぶった状態で、回避策としてコンストラクターを非表示にする必要があります。私の（およびコミュニティの）意見では、言語には有用なものが欠けているためです。

興味深いことに、TypeScriptチームがテーブルの周りに座ってabstractクラスについて話し合ったとき、誰かが手を挙げて「でもfinalどうですか？」と言いましたか？

@RyanCavanaughうーん私はあなたのポイントを理解しています

ほとんどの場合、それは誤解だったと思います（私たちが説明した方法から推測します）

@ series0neの要約は、JSで最終クラスを作成するように要求することで、タイプスクリプトの出力をそれほど複雑にすることではなく（これは、そうするための列車の大破になるでしょう）、人々に伝えるための追加のルールを作成することでした。 tそれをします。 そして、APIのユーザーに、出力ではなく、typescriptファイル/コンパイラーのすべてでそれらのクラスを（安定性、セキュリティ上の理由などで）混乱させてはならないことを伝えます。

この機能があるといいと思いますか：はい、いくつかのテクニックを実行するためのより高速な方法があるといいです。

それは本当に必要ですか？ 実際には、これは思いやりのあるマイナーなものである可能性があり、Typescriptチームがこの追加を実装する余裕がある場合は、優先すべきではありません。

最終/封印されたキーワードは、特にバグ修正、パッチ、動作の変更など、多くの側面を複雑にする可能性があることはわかります。

これを説明すると、すべてのクラスが拡張されないようにロックすることで、finalの乱用が完全に見られます。 対処すべきa **の大きな苦痛をIMOに引き起こします。 「セキュリティ」のために偏執的だったため、継承によってユーザークラスに変更を加えるためにロックされているAPIを使用したくありません。

これは、自分のニーズに合わせてこのクラスの動作を変更できるようにするために、プロトタイプを使用してから、このクラスをエイリアスまたはオーバーライドする必要があることを意味します。
これは、特に、前述のクラスに機能を追加したいだけで、破壊的なワークフローを実行したくない場合は面倒です。

この後、私は今の状況を誤解しているかもしれませんが、私にそれを自由に説明してください:)

ああ、私がES4についてたくさん読んでいたことを思い出すと（ドラフトが制作中だったとき、私はまだ子供だったとは思いませんが）、驚くべきことに、Typescriptに非常によく似ています。

そしてそれはここのドラフト仕様で言う：
https://www.ecma-international.org/activities/Languages/Language%20overview.pdf

A class that does not explicitly extend any other class is said to extend the class Object. As a consequence, all the classes that exist form an inheritance hierarchy that is a tree, the root of which is Object. A class designated as final cannot be extended, and final methods cannot be overridden: class C { final function f(n) { return n*2 } } final class D extends C { function g() { return 37 } }

そのため、技術的には、最終的なキーワードがEcmascript第4版で計画されました。 JSの将来の統合でそれが表示されるかどうかは疑問ですが、実際にクラスが統合されているため、これは可能かもしれませんが、誰が知っていますか？

私は、この問題を見つけるために私を駆り立てた、ほとんど遭遇しなかった1つのユースケースがあります。 これは、リターンタイプとしてのthisの使用を中心に展開します。

abstract class TileEntity {
    //constructor, other methods...
    abstract cloneAt(x: number, y: number): this;
}

これを書いた私の意図は、TileEntitiesが不変である（したがって、安全に渡すことができる）ことを保証することでしたが、特定のTileEntityは、いくつかの変更されたプロパティ（この場合はxとy ）で複製できます。 ）サブクラスの形状について何も知る必要はありません。 それが私が書きたいことですが、実装を（正しく）書き込もうとすると、これが壊れます。

class TurretTileEntity extends TileEntity {
    //constructor, other methods...
    cloneAt(x: number, y: number): this {
        return new TurretTileEntity(x, y, /* ... other properties */);
    }
}

問題は、TurretTileEntityのサブクラスが存在しないことを宣言できなければ、 this戻り型をTurretTileEntity型だけに絞り込むことができないことです。

戻り値を<any>キャストできることを考えると、Typescriptのこの欠点の影響は最小限です。 これは、客観的にはアンチパターンであり、型システムがより表現力豊かである可能性があることを示す有用な指標です。 最終/封印されたクラスをサポートする必要があります。

興味深いことに、TypeScriptチームがテーブルの周りに座って抽象クラスについて話し合ったとき、誰かが手を挙げて「しかし、finalはどうですか」と言いましたか？

はい。 キーワードを追加するたびに、「しかし、この他のキーワードも追加する必要があります！」 言語をできるだけ注意深く成長させたいので、それを追加することに対する長所です。 クラス宣言のfinalもこのキャンプにあります- finalクラスがある場合は、 finalメソッドまたはプロパティも「必要」になります。 スコープクリープのように見えるものはすべて、非常に疑わしいと見なされます。

最終的なクラスとメソッドは非常に重要だと思います。 実装していただければ幸いです。

この問題は最終/封印されたクラスに関するものであることに注意してください。 まったく異なる概念である最終/封印された方法についてのトピック外の議論がありました。

mhegazyは、この問題を支持してhttps://github.com/Microsoft/TypeScript/issues/9264を閉じました。 最終/封印された方法を追跡するための重複としてクローズされていない別の問題はありますか？

@crcla上記の@RyanCavanaughのコメントのいくつかを読んだことから、他の問題を閉じる理由は、final / sealedクラスのサポートにはfinal / sealedメソッドのサポートが含まれるためだと思います。 この2つは、非常に密接に関連するトピックです。

私はのための提案を信じることができないfinalとしてラベル付けされたWon't fix 。

ラベルをIn Discussion戻し、実装してください。

私の場合、プラグインの抽象基本クラスを作成し、プラグインクラスが誤って基本クラスのメソッドを上書きできないようにしたいです。 private constructor 、 Object.sealどれもこの仕事をすることができません。

これを重要なライブオアダイ機能と見なしている人にとっては、実際にはそうではありません。 APIが、コンシューマーによって拡張される必要があるクラス実装を公開することで構成されている場合、これを行うためのより良い方法があります。 Reactの悪い例に従わないでください。 関数と単純なオブジェクトを使用し、このOOをそれが属する場所にナンセンスのままにします：過去。

今すぐ反対票を持ってきてください😀

この議論が最終クラスと最終メソッドをどのように区別しないかを誰かが私に説明できますか？ もちろん、一部のメソッドがオーバーライドされないようにすることは、非常に大きな価値をもたらします。 プラグイン開発者がフレームワーククラスの一部をサブクラス化し、抽象関数を実装することで機能を追加できるようにしたいのですが、同時に、これらの抽象関数を呼び出すメソッドを（そしてなぜ！）オーバーライドしないようにしてください。エラー処理/ログイン/チェックが行われていることを確認してください。

@pelotom OOP構造とパターンを使用したくない場合は、使用しないでください。他の方法を使用するように指示されることはありませんが、反対方向にも同じことが当てはまります。誰かがOOP構造を使用したい場合は、そのままにします。
他の人に特定の（非OOP）パターンを採用するように強制することで、OOPを非難するのと同じ動作を採用することになります。 少なくとも一貫性がある:)

TypeScriptにfinalキーワードを追加することは、重大な変更ではなく、既存のプロジェクトに影響を与えることはありませんが、 @ thorek 、私、および他の多くの人々にとって重要な機能になります。

誰かがOOP構造を使用したい場合は、そのままにしてください。

私たちは人々がOOP構造を使うべきかどうかを議論しているのではなく、現在存在しないOOP構造を言語に追加すべきかどうかを議論しています。 これを行うと、他の機能に費やされる可能性のある開発者の時間がかかり、言語がより複雑になり、将来の機能の速度が遅くなります（新しい機能ごとに、古い機能との相互作用を考慮する必要があるため）。 TypeScriptの開発と複雑さの予算をもっと便利なものに費やしたいので、それは確かに私に影響を与えます！

fwiw、おそらくお客様（google）にコメントで@finalを使用するように勧めて、クロージャーコンパイラーに伝播するようにします：\

クラスとメソッドに_final_を追加すると、R＆Dチームが他のチームが使用できるTSライブラリを構築するときに役立ちます。 これらのキーワードは、そのようなツールのサービス露出の安定性の（重要な）部分です。
キーワードは、大規模なチームにとってはより重要であり、小規模なプロジェクトにとってはそれほど重要ではありません。

@dimiVergosこれはまさに私の場合であり、他の多くの人にも同じだと思います。 私は自分の立場のために偏見があるように見えるかもしれませんが、私の経験によれば、このキーワードの唯一の（非常にではありますが）正当な使用法のようです。

私はこれについての訂正を受け入れています！

私は最終クラスよりも（サブクラスが誤ってそれらをオーバーライドするのを避けるために）最終メソッドをサポートすることに関心があります。 それに投票するのに適切なチケットはありますか？ チケットhttps://github.com/Microsoft/TypeScript/issues/9264はそう示唆しているようです。

では、どうすれば「最終的な方法」に投票できますか？ それとも、このコメントで投票しただけですか？ また、タイトルに「メソッド」を追加するにはどうすればよいですか？ 編集できますか？ 現在のタイトルは誤解を招くようにクラスのみに限定されていますが、ディスカッションにはメソッドも含まれています。

他の多くの人と同じように、TypeScriptの最終的なメソッドを見たいと思います。 私は、失敗の影響を受けない部分的な回避策として次のアプローチを使用しましたが、少なくとも少しは役立ちます。

class parent {
  public get finalMethod(): () => void {
    return () => {
      // final logic
    };
  }
}

class child extends parent {
  // ERROR "Class 'parent' defines instance member accessor 'finalMethod', but extended class 'child' defines it as instance member function"
  public finalMethod(): void { }
}

finalメソッドのもう1つの実際のユースケースを次に示します。 単純なコンテキストの実装を容易にするために、次のReact.Component拡張を検討してください。

interface FooStore{
  foo: string;
}

const {Provider, Consumer} = React.createContext<FooStore>({
  foo: 'bar';
});

abstract class FooConsumerComponent<P, S> extends React.Component<P, S> {

  // implement this instead of render
  public abstract renderWithStore(store: FooStore): JSX.Element;

  public final render() {
    return (
      <Consumer>
        {
          (store) => {
            return this.renderWithStore(store);
          }
        }
      </Consumer>
    );
  }
}

render()メソッドにfinalがないと、メソッドを誤ってオーバーライドしてすべてを壊してしまうのを防ぐことはできません。

こんにちは、他の多くの人と同じように、少なくともメソッドには「final」または「sealed」キーワードが必要です。 このキーワードは、開発者がライブラリの顧客が重要なコードブロックを拡張するのを防ぐことができるため（プラグインなど）、本当に付加価値があることに完全に同意します。

私が見つけた唯一の回避策は、次のようなメソッドデコレータを使用することです。
function sealed(target, key,descriptor){ descriptor.writable = false; // Prevent method to be overriden }

次に、「基本」クラスで、デコレータを使用してメソッドのオーバーライドを防止します。例：

class MyBaseClass {
<strong i="10">@sealed</strong>
public MySealedMethod(){}

public OtherMethod(){}

...
}

このように、「MySealedMethod」はサブクラスで（簡単に）オーバーライドできませんでした。 例：

class AnotherClass extends MyBaseClass {
public MySealedMethod(){} ====>> ERROR at RUNTIME (not at compile time)
}

実際、この回避策の唯一の欠点は、「封印された」が実行時にのみ表示され（javascriptコンソールのエラー）、コンパイル時には表示されないことです（メソッドのプロパティは関数を介して設定されるため）

@RyanCavanaugh

はい。 キーワードを追加するたびに、「しかし、この他のキーワードも追加する必要があります！」 言語をできるだけ注意深く成長させたいので、それを追加することに対する長所です。

あなたはこの議論を、この機能に反対する心を持って始めているように思えます。 人気のある機能は、そのような機能を検討することに反対するポイントであってはなりません。 _なぜ人気があるのか​​_を自問し、慎重に検討することがポイントになるはずです。

あなたはそれについて議論し、それを検討するか反対するかについて議論が飛び交っていると確信しています。 それに対する議論は、それがフィーチャークリープであるというだけですか、それとももっと具体的なものがありますか？ フリンジ機能だと思いますか？ もしそうなら、私たちはあなたの心を変えるために何かをすることができますか？

私たち全員が熟考するために、これらの質問をここに残しておきましょう。

現在の構成を使用して_設計によって_クラスをシールする方法はありますか？
機能が追加された場合、それは私たちに何か新しいことをすることを可能にしますか？ （のように、現在の構成では許可されないもの）
その機能が私たちに何か新しいことをすることを可能にしたなら、それは何か価値がありますか？
封印されたクラスを追加すると、言語の複雑さが増しすぎますか？
封印されたクラスを追加すると、コンパイラの複雑さが増しすぎますか？

これらについて説明するために、私は封印されたメソッドを説明に含めていません。また、実装に実行時チェックも含めていません。 これをJavascriptに適用できないことは誰もが理解しています。

参考までに：この機能への対抗策が、フィーチャークリープに対する単なる包括的な声明以上のものであるとしたら、私は素晴らしいと思います。

@asimonfあなたが言ったことはすべて、このコメント（「もっと見る」セクションを展開して表示する必要があります）とそれに続く

ここで私たちの心を変えるものは何ですか？ sealedキーワードが欠落しているために、 例が表示されます。

キーワードが対処しようとするここでのシナリオは、誰かが誤ってクラスから継承するシナリオです。 どのようにして誤ってクラスから継承しますか？ 簡単な間違いではありません。 JavaScriptクラスは本質的に脆弱であるため、サブクラスは基本クラスの動作要件を理解する

そもそもそこにいないことを告げる少なくとも2つの別々の障害に遭遇するはずの状況がすでにあるのに、TypeScriptにこのキーワードが必要なのはなぜですか？

私は約永遠にプログラミングを続けてきましたが、何かが封印されていることを確認するためだけにサブクラス化を試みたことは一度もありません。 私が天才だからじゃない！ これは非常にまれな間違いであり、JavaScriptでは、これらの状況は、そもそも基本クラスに質問する必要がある状況になっています。 では、どのような問題が解決さ

私がfinalを使用する実際のケースは、スーパーメソッドを呼び出さないものでメソッドをオーバーライドしないようにすることです。 もちろん、いくつかの公開メソッド。 しかし、私が理解した本当の解決策は、サブメソッドにスーパーメソッドを呼び出すように強制する機能です。 https://github.com/Microsoft/TypeScript/issues/21388

私は言語デザイナーではないので、言語にキーワードを追加することの欠点について話すことはできません。 私は現在、最終的にしようとしているメソッドを持つ抽象スーパークラスに取り組んでいると言いますが、残念ながら、そうすることができませんでした。 今のところ、コメントを付けるという理想的とは言えないアプローチを採用しますが、クラスを実装するチームメンバーはそのコメントを読まない可能性があります。

上記には、 finalが役立つだけでなく、構築中のプラットフォームに_実際の価値_と_実際の安全性_を提供する優れた例がたくさんあると思います。 それは私にとっても違いはありません。 私が言ったように、私は言語設計の複雑さについてあまり知りませんが、これは明らかに人々が望んでいる/使用する/それを悪用する方法が本当にわからない、またはそれが悪いコードを生成する機能です。 スコープクリープを恐れるという概念は理解していますが、TS開発者はコミュニティが望むすべてを実装する必要はありません。

議論に私のビットを追加するために、この問題は機能の追加をサポートする良い議論でいっぱいですが、私が見る反対の議論は次のとおりですので、私はスケールのイエス側に親指を置きたいと思います。

• スコープクリープにつながる可能性があります（これは管理可能です）
• 人々は他の機能を要求するでしょう（大丈夫ですが、誰が気にしますか、それは言語の設計の一部であり、これは私たちが設定している法的前例ではありません）
• 効率が低下する可能性があります（TSチームは悪い評価でいっぱいなので、おそらくこれを管理しやすくする方法を見つけるでしょう）
• 「OOPの概念を使用しないでください」という意見のコメント

上記のいずれも、TSエコシステム自体、またはそれから生成されるコードに対する信頼できる脅威のようには見えません。 それらはすべて政治的であるように見えます（おそらく効率のものを除いて、私はあなたたちに大きな自信を持っているので、私はそれについて本当に心配していません、そしてわずかな効率の低下は無意識の継承の間違いによって重要なコンポーネント/ライブラリ構造を爆破しない価値があります） 。

これが建設的であることを願っています！ TSが大好きで、それが改善され続けるのを見たいです！

👍

- 編集 -

@RyanCavanaughへの

So what problem is being solved?

解決されている問題は、上記の多くのコメントによって概説されていると思います。 私はこれを侮辱として意味するのではありませんが、その質問は、あなたが提示された議論に実際に注意を払っていないように、そしてあなたが「ノー」にあなたの心を設定しているように、私にはそれを聞こえさせます。 私はそれを軽視するつもりはありません、それだけで、正直なところ、このスレッドはこれが解決するであろう問題の例でいっぱいです。

どういうわけか私はこのコメントを見逃しました。それは機能を追加することへの深刻な懸念を非常によく概説していて、それは私にとって理にかなっています。 繰り返しになりますが、追加の複雑さはわかりませんが、効率の問題はさておき（TSの効率について心配するのは開発者の責任ではないため、TSチームの仕事です）、ファイナルに反対する良い議論はないようです。 （私の最も謙虚な意見で）。

最近の議論のほとんどは、最終的なメソッドに集中してい@RyanCavanaughの以前の投稿の「このコメント」リンクを展開すると、彼は最終的なメソッドの議論をトピックから外していると見なしていることに@ mhegazyは、このチケットが適切な場所であることを示唆しました（＃9264を閉じるとき）。 ですから、エンドユーザーの少ない私は、最終的な方法をどこに求めたり、投票したりするべきかについて困惑してい

@cbutterfield
矛盾は私も気づいたものですが、暴言を恐れて私の投稿では指摘しませんでした（私は実際にこのスレッドを＃9264で@ mhegazyの指示でここに来ました）。
@RyanCavanaugh
@mhegazy
上記のコメントによると、最終的な方法を議論するのに適切な場所です。これは、実際に私が最も興味を持っていることだからです。

非常に反対意見のコメントを振り返ります（まだ追加していない場合は、必ず👎を追加してください！） classベースのAPIを強制することで、Reactが悪い例を設定することは_もはや_ないことを報告できてうれしいです。そのユーザーに！ Hooksの提案により、Reactチームは彼らの感覚を理解し、根本的に単純な機能的アプローチを採用しました。 それで、多くの開発者がクラスをまったく使用しなければならない最後の理由はなくなり、良い馬鹿げたことになりました。 繰り返しになりますが、クラスが必要だと思われるものはすべて、クラスがなくてもより適切に実行できます。

JSとTSの未来はクラスレスです、賞賛してください！

@cbutterfield私も気づきました。この号で議論するために問題＃9264が閉じられた場合、タイトルをSuggestion: Final keyword for classes and methodsに変更する必要があると思います。そうしないと、最終的な方法を探している人は（排他的に）反応を追加しない可能性があります。最初の投稿。

@mhegazyの引用：
JavaやC＃は、 finalクラスを使用して、実行時にクラスを最適化します。これは、クラスが特殊化されないことを認識しています。 これが最終的なサポートの主な価値であると私は主張します。 TypeScriptでは、finalを使用しない場合よりもコードを実行しやすくするために提供できるものはありません。

私は根本的に同意しません。 私は多くのチームで長年Javaで開発してきましたが、ランタイムの最適化に最終的なクラスやメソッドを使用したことはありません。 実際には、これは主にOOP設計イディオムです。 関数を保護して保証するため、ライブラリのAPIノイズを本質的なものに制限するため、またはAPIユーザーが複雑なAPIを誤解しないようにするために、クラスまたはメソッドを外部サブクラスによって拡張/オーバーライドしたくない場合があります。

はい、これらの問題はコメントやインターフェースを追加することで解決できますが、 finalは、クリーンで拡張可能なAPIを備えた単純なクラスだけが必要な場合に、表示されるAPIを必要な関数に減らすための洗練されたソリューションです。

この問題は3年近く前のものですが、すでにabstractキーワードがあるため、実際にはfinalキーワードが必要です。

人々にそれを強制的に使用させたくないこと、そしてそれはabstractキーワードと同じくらい便利な機能であることを覚えておいてください。 しかし、 finalキーワードの利点を強く示す別のユースケースは次のとおりです。

abstract class A {
  protected abstract myVar: string;

  protected abstract myFunction(): void;
}

class B extends A {
  protected readonly myVar: string = "toto";

  constructor() {
    super();
    this.myFunction();
  }

  protected myFunction() {
    console.log(this.myVar);
  }
}

class C extends B {
  constructor() {
    super();
  }

  protected myFunction() {
    console.log("tata");
  };

  public callFunction = () => {
    this.myFunction();
  }
}

const myB = new B(); // toto

const myC = new C(); // toto
myC.callFunction(); // tata

コンパイル後の結果：

toto
tata

したがって、このコードでは、抽象メソッドとプロパティを持つ抽象クラスAがあり、継承されたクラスでそれらを定義する必要がありますが、他のクラスがそれらの実装をオーバーライドしないようにします。
protectedキーワードを保持するのが最善の方法ですが、ご覧のとおり、属性を再定義することはできます。

では、Typescriptのコンパイルプロセスをさらに進めて、 readonlyを使用して属性を保護するとしたらどうなるでしょうか（そして、メソッドがプロパティであると偽って）。

class B extends A {
  [...]

  protected readonly myFunction = () => {
    console.log(this.myVar);
  }
}

class C extends B {
  protected myVar: string = "I am not protected that much";
  [...]

  protected myFunction = () => { // using the readonly keyword doesn't prevent any modification
    console.log("tata"); // If you launch this code, tata will still be logged in the console.
  };
}

（コードはtscでコンパイルされ、コンパイルまたは実行時にエラーがスローされないことに注意してください）
したがって、2つの問題があります。

• B属性は保護されていないため、予期しない継承を防ぐ方法が必要です。
• これで、クラスを拡張することでreadonlyプロパティをオーバーライドできることがわかりました。はい、Typescriptは、 protected代わりにprivateを使用するように変更する親プロパティであることを認識しています。 Cクラスでは、同じアクセスタイプ/可視性ではないため、エラーがスローされます。

現時点では、デコレータ（公式のTypescriptドキュメントが示すように封印されているか、最終的なデコレータ）を使用できますが、実行時にのみ有用であり、代わりにコンパイルプロセスでこれを防ぐ必要があることに注意してください。

保護された読み取り専用値をオーバーライドしたいが、実際には可能であり、すべきではない場合に、「セキュリティ違反」（それを呼び出すことができる場合）に関する問題があるかどうかを調べます。 それ以外の場合は、 private 、 protectedキーワードの中で、継承関連のものを使用したreadonlyキーワードの検証について議論する問題を開きます。

tl; dr： finalキーワードは2つの問題を解決します（ただし、 readonly検証は、不正な書き換えを防ぐための良いスタートです）

3年後...それはとてもばかげています。

この機能の必要性を証明するために、他の言語で何が行われたかを確認することをお勧めします。

Java:
final class SomeClass { ... }
PHP:
final class SomeClass { ... }
C#:
sealed class SomeClass {...}
C++:
class SomeClass final { ... }
Delphi:
type SomeClass = class sealed() ... end;

したがって、最も一般的なすべてのOOP言語で、この機能はOOPの継承ロジックに由来するために存在することがわかります。

また、TSの開発リーダーの言葉を引用する必要があります

最終クラスがある場合は、最終メソッドまたはプロパティも「必要」になります。

皮肉なことかどうかはわかりませんが、JSではreadonlyキーワードがプロパティ（およびチートする場合はメソッド）に使用されるため、これはかなり馬鹿げた点です。

そして、コミュニティが彼に強く反対していることを意味する+40の反対票を持っているときに、一人の男に問題を終わらせないことは、さらなる愚かな状況を避けるための良いアドバイスでしょう。

Typescriptの主な機能を強化することに興味がない場合は、技術ニュースがTwitterでそれを中継できるように、大声で言ってください。そうしないと、隠れた悪い話題になります。 あなたは自分のコミュニティを無視しているだけであり、コミュニティに私たちが必要かどうかを検証させるプロセスはありません。

+40の反対票があるときに、1人の男に問題を終わらせないようにすることは、コミュニティが彼に強く反対することを意味します。これ以上の愚かな状況を避けるための良いアドバイスです。

私は「一人の男」ではありません。 ここで決定を下すとき、それはTypeScriptチーム全体の意思決定プロセスを反映しています。 設計チームは、この問題で複数回見てきましたし、毎回同じ結論に来ます。 あなたはその結果に反対することを歓迎しますが、プロセスは議論の余地がありません。

コミュニティに私たちが必要かどうかを検証させるプロセスはありません。

これがプロセスです。ここで、あなたは私たちの推論の要約を「ばかげた」と呼び、私（およびチームの他の人々）はそれを読んでいます。 私たちはフィードバックを聞いています。

これを検討する理由として他の実装された機能を指摘することは匂いであり、実際には議論ではないことを私は知っていますが、タイプエイリアシングメカニズムが考慮されて追加されたのは皮肉です（それは素晴らしいかもしれませんが、それなしで生きることは確かです）しかし、このようなものは拒否されます。

結局、私はそのような機能なしで生きることができますが、TSが持っている機能の約半分についても同じことが言えます。 では、これを実装することを検討する適切な理由は何でしょうか？

GitHubはここに多くのコメントを隠してしまうので、過去に行ったさまざまな回答（およびいくつかの追加）を再投稿します。 以下にもいくつかの考えを追加します。

前回レビューした際にいくつかの点が考慮されました

• クラスはJAVASCRIPT機能であり、TYPESCRIPT機能ではありません。 finalないとクラスがまったく役に立たないと本当に感じた場合、それはTC39委員会で取り上げるか、es-discussに持ち込むものです。 finalが必須の機能であることをTC39に納得させようとしない、または納得させることができない場合は、TypeScriptに追加することを検討できます。
• 何かに対してnewを呼び出すことが合法である場合、それはそれから継承することと1対1のランタイム対応を持っています。 new 'dであるが、 super ' dではないものの概念はJavaScriptには存在しません
• TypeScriptがOOPキーワードスープにならないように最善を尽くしています。 JavaScriptの継承よりも優れた構成メカニズムが多数あり、C＃とJavaが持つすべてのキーワードを用意する必要は
• ランタイムチェックを簡単に記述して、「最終的な」クラスからの継承を検出できます。これは、すべてのコンシューマーがTypeScriptを使用しているとは限らないため、誰かが誤ってクラスから継承することを「心配」している場合は、とにかく実行する必要があります。 。
• lintルールを記述して、特定のクラスが継承されないスタイルの規則を適用できます。
• 誰かがあなたの封印されるべきクラスから「偶然に」継承するというシナリオは、一種の奇妙なものです。 また、特定のクラスから継承することが「可能」であるかどうかについての誰かの個別の評価は、おそらくかなり疑わしいと思います。
• クラスを封印する理由は基本的に3つあります。セキュリティ、パフォーマンス、意図です。 これらのうちの2つは、TypeScriptでは意味がないため、他のランタイムで実行するジョブの3分の1しか実行しないものの複雑さとゲインを考慮する必要があります。

TSがそれを必要としない理由についての説得力のある議論を聞いたことがありません

これはそれがどのように機能するかではないことを思い出してください。 すべての機能は-100から始まります。 その投稿から

それらの質問のいくつかでは、質問は、なぜ特定の機能を「削除」または「除外」したのかを尋ねます。 この言い回しは、既存の言語（ここでは、C ++とJavaが一般的な選択肢です）から始めて、好きなところまで機能を削除し始めたことを意味します。 そして、信じがたい人もいるかもしれませんが、それは言語が設計された方法ではありません。

複雑さの予算には限りがあります。 私たちが行うすべてのことは、私たちが行う次のすべてのことを0.1％遅くします。 機能をリクエストすると、他のすべての機能が少し難しくなり、少し遅くなり、可能性が少し低くなるように要求します。 Javaがそれを持っているか、C＃がそれを持っているか、それがほんの数行のコードであるか、コマンドラインスイッチを追加できるため、ここでは何も入りません。 機能は、それ自体と将来の負担全体に対して支払う必要があります。

ここで私たちの心を変えるものは何ですか？ finalキーワードが欠落しているために、 例が表示されます。

キーワードが対処しようとするここでのシナリオは、誰かが誤ってクラスから継承するシナリオです。 どのようにして誤ってクラスから継承しますか？ 簡単な間違いではありません。 JavaScriptクラスは本質的に脆弱であるため、サブクラスは基本クラスの動作要件を理解する

言い換えると、JavaScriptでクラスから継承するための唯一の正しいプロセスは、常にそのクラスのドキュメントを読むことから始まります。 基本クラスが単純に導出してコーディングを開始しなければならない制約が多すぎます。 最初のステップで、試行しないことをすでに知っている必要がある場合、静的強制はステップ3でどのような値を提供しますか？

そもそもそこにいないことを告げる少なくとも2つの別々の障害に遭遇するはずの状況がすでにあるのに、TypeScriptにこのキーワードが必要なのはなぜですか？

私は約永遠にプログラミングを続けてきましたが、何かが封印されていることを確認するためだけにサブクラス化を試みたことは一度もありません。 私が天才だからじゃない！ これは非常にまれな間違いであり、JavaScriptでは、これらの状況は、そもそも基本クラスに質問する必要がある状況になっています。 では、どのような問題が解決さ

Typescriptの主な機能を強化することに興味がない場合は、技術ニュースがTwitterでそれを中継できるように、大声で言ってください

言語の設計方法については非常に明確です。 目標ではないナンバーワンは、この提案を正確に物語っています。

ここで多くのコメントを読んだ後の私の個人的な反応は、他の言語に存在する構造による強いバイアス効果があるということです。 白紙の状態の観点からこれにアプローチすると、想像できる行動が数十ありますが、TypeScriptには小さなサブセットしかありません。

メソッドに適用され、派生メソッドがsuper介してそれを呼び出すように強制されたキーワードを簡単に想像できます。 C＃とJavaにこのキーワードがあれば、人々はそれが理にかなっている場所にそのキーワードを絶対に適用するでしょう。 実際、ランタイムチェックを適用することは不可能であり、「派生クラスが存在しない可能性がある」よりも基本派生コントラクトのはるかに微妙な側面であるため、 finalよりもはるかに一般的に適用されます。 "。 finalはないさまざまな方法で役立ちます。 私はこれよりもむしろそのキーワードを持っていると思います（どちらも複雑さと価値のバーを満たしていないと思いますが）。

では、これを実装することを検討する適切な理由は何でしょうか？

フィードバックを見ると、次のような強力な考慮事項があります。

• このJavaScriptライブラリの動作を適切に表現できません
• 私のコードはコンパイルされましたが、この（微妙な）エラーがあったため、実際にはコンパイルされるべきではありません
• このコードの意図は、型システムによって適切に伝達されていません

finalはこれらに当てはまりますが、「この関数を2回続けて呼び出すことはできません」または「このクラスの構築は次の非同期ティックまで実際には終了しません」という修飾子も当てはまります。 想像できるすべてのものが存在する必要はありません。

「実際にはサブクラス化できないクラスから継承しようとしたため、デバッグに何時間も費やした」などのフィードバックは見たことがありません。実際には想像できないため、「ワット」が正しくトリガーされると誰かが言っています。 修飾子が存在したとしても、クラスが最終的なものであるかどうかをライブラリが文書化しないため、実際には状況を改善しません。たとえば、 fs.FSwatcher final ？ ノードの作者でさえ知らないようです。 したがって、作成者がfinalであることを知っていれば、 finalで十分ですが、それは関係なく文書化されます。 finalがない場合は、多くの場合、実際には何もわかりません。どちらの方法も知られていないだけです。

ブロック全体を読み、機能の選択に関するチームの声明を理解しました。コメントから特定のポイントに戻ります。

私は「一人の男」ではありません。 ここで決定を下すとき、それはTypeScriptチーム全体の意思決定プロセスを反映しています。

申し訳ありませんが、私はmhegazyと、Typescriptを使用するコミュニティから彼が得たかなり大規模なフィードバックについて言及していました。

ファイナルなしではクラスが完全に役に立たないと本当に感じた場合、それはTC39委員会で取り上げるか、es-discussに持ち込むものです。 ファイナルが必須の機能であることをTC39に納得させる意思がない、または納得できない場合は、TypeScriptに追加することを検討できます。

privateキーワードの提案がすでにあるため、 finalが最初のステップではないと思いますhttps://github.com/tc39/proposal-private-methods

私はYou should a comment to say *dont do this*に懐疑的です、それはフォームHey don't write down specific charactersで言っているようなものです、あなたはほぼ永遠にコーディングしたので、開発者のn°1ルールを知っている必要があります：ユーザーを信頼しないでください（およびコードを使用する開発者）

ユースケースが低すぎて効率的ではないため、すべてを完全に停止し、最終的なキーワードを実装するために10億ドルを投入する必要があると言っているわけではありません。また、制限がTSとJSの両方からのものである例をいくつか挙げたことも考慮してください。人々がTSを選択した場合、それは実行時ではなくコンパイル時のエラーを防ぐためです。 実行時に爆発させたい場合は、JSを使用してTSのことを気にするのをやめることができますが、 finalキーワードの使用方法を示す究極のユースケースがあるため、それは重要ではありません。メソッド、私は誰にもそれを上書きしてほしくない。

Javascriptはそれによって制限されているため、コミュニティはTypescriptがその制限を超える可能性があると考えていました。そのため、この問題は3年間続いています。そのため、この機能がここにないのはなぜかと人々はまだ疑問に思っています。そのため、コンパイラにクラスやメソッドの手動チェックを行います。

JSがそれらを実装するためのプライベート/パブリックメソッドを持っているのを待ちませんでしたが、実際にはそれらを#キーワードに含める提案があります（ public / privateよりも冗長ではありません） ）、完璧な言語を作成したかったのはわかっています。完璧とは、何も追加できなくなったときではなく、何も削除できなくなったときだからです。

コンパイルプロセスでメソッドが上書きされるのを防ぐための解決策を見つけることができたら（ポイントが有効ではないため、ランタイムプロセスでは上書きされません）、私のゲストになります。

私は状況の弱点（クラスではなくメソッド/プロパティ）を示しようとしました。TS開発者は必要なライブラリを書き換えて、必要なものを壊すことができるからです。おそらくそれが美しさだと思います。

ちなみに返信ありがとうございます。開発チームやあなたに対する憎悪や悪い行動はありません。

すべての有効なポイント！ しかし、議論をに分けてみましょう

a）最終クラスをサポートする
b）最終的な方法をサポートする

すべての引数はa）を対象としていますが、bを対象とするものはありません。

議論で何度も指摘されたように、最終的な方法を持つことは非常に重要です。 私がこれまで聞いた唯一の答えは「OOPをしない」でした-しかし、それは私（そして他の多くの人）が一緒に行くことではありません。

アム2019年1月28日20時32 umのschriebライアンCavanaughの[email protected] ：

GitHubはここに多くのコメントを隠してしまうので、過去に行ったさまざまな回答（およびいくつかの追加）を再投稿します。 以下にもいくつかの考えを追加します。

前回レビューした際にいくつかの点が考慮されました

クラスはJAVASCRIPT機能であり、TYPESCRIPT機能ではありません。 ファイナルなしではクラスが完全に役に立たないと本当に感じた場合、それはTC39委員会で取り上げるか、es-discussに持ち込むものです。 ファイナルが必須の機能であることをTC39に納得させる意思がない、または納得できない場合は、TypeScriptに追加することを検討できます。
何かに対してnewを呼び出すことが合法である場合、それはそれから継承することと1対1のランタイム対応を持っています。 新しくすることはできるが、スーパーにすることはできないという概念は、JavaScriptには存在しません。
TypeScriptがOOPキーワードスープにならないように最善を尽くしています。 JavaScriptの継承よりも優れた構成メカニズムが多数あり、C＃とJavaが持つすべてのキーワードを用意する必要はありません。
ランタイムチェックを簡単に記述して、「最終的な」クラスからの継承を検出できます。これは、すべてのコンシューマーがTypeScriptを使用しているとは限らないため、誰かが誤ってクラスから継承することを「心配」している場合は、とにかく実行する必要があります。 。
lintルールを記述して、特定のクラスが継承されないスタイルの規則を適用できます。
誰かがあなたの封印されるべきクラスから「偶然に」継承するというシナリオは、一種の奇妙なものです。 また、特定のクラスから継承することが「可能」であるかどうかについての誰かの個別の評価は、おそらくかなり疑わしいと思います。
クラスを封印する理由は基本的に3つあります。セキュリティ、パフォーマンス、意図です。 これらのうちの2つは、TypeScriptでは意味がないため、他のランタイムで実行するジョブの3分の1しか実行しないものの複雑さとゲインを考慮する必要があります。
TSがそれを必要としない理由についての説得力のある議論を聞いたことがありません

これはそれがどのように機能するかではないことを思い出してください。 すべての機能は-100https ： //blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/から始まり

それらの質問のいくつかでは、質問は、なぜ特定の機能を「削除」または「除外」したのかを尋ねます。 この言い回しは、既存の言語（ここでは、C ++とJavaが一般的な選択肢です）から始めて、好きなところまで機能を削除し始めたことを意味します。 そして、信じがたい人もいるかもしれませんが、それは言語が設計された方法ではありません。

複雑さの予算には限りがあります。 私たちが行うすべてのことは、私たちが行う次のすべてのことを0.1％遅くします。 機能をリクエストすると、他のすべての機能が少し難しくなり、少し遅くなり、可能性が少し低くなるように要求します。 Javaがそれを持っているか、C＃がそれを持っているか、それがほんの数行のコードであるか、コマンドラインスイッチを追加できるため、ここでは何も入りません。 機能は、それ自体と将来の負担全体に対して支払う必要があります。

ここで私たちの心を変えるものは何ですか？ 最後のキーワードが欠落しているために、本来の方法で機能しなかったコードの例が表示されます。

キーワードが対処しようとするここでのシナリオは、誰かが誤ってクラスから継承するシナリオです。 どのようにして誤ってクラスから継承しますか？ 簡単な間違いではありません。 JavaScriptクラスは本質的に脆弱であるため、サブクラスはその基本クラスの動作要件を理解する必要があります。つまり、何らかの形式のドキュメントを作成する必要があり、そのドキュメントの最初の行は単に「このクラスをサブクラス化しないでください」にすることができます。 または、ランタイムチェックを行うこともできます。 または、クラスコンストラクタをファクトリメソッドの背後に隠すことができます。 または他の数のオプション。

言い換えると、JavaScriptでクラスから継承するための唯一の正しいプロセスは、常にそのクラスのドキュメントを読むことから始まります。 基本クラスが単純に導出してコーディングを開始しなければならない制約が多すぎます。 最初のステップで、試行しないことをすでに知っている必要がある場合、ステップ3で静的強制が提供する値は何ですか？

そもそもそこにいないことを告げる少なくとも2つの別々の障害に遭遇するはずの状況がすでにあるのに、TypeScriptにこのキーワードが必要なのはなぜですか？

私は約永遠にプログラミングを続けてきましたが、何かが封印されていることを確認するためだけにサブクラス化を試みたことは一度もありません。 私が天才だからじゃない！ これは非常にまれな間違いであり、JavaScriptでは、これらの状況は、そもそも基本クラスに質問する必要がある状況になっています。 では、どのような問題が解決されているのでしょうか。

Typescriptの主な機能を強化することに興味がない場合は、技術ニュースがTwitterでそれを中継できるように、大声で言ってください

言語の設計方法については非常に明確ですhttps://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals ; 目標ではないナンバーワンは、この提案を正確に物語っています。

ここで多くのコメントを読んだ後の私の個人的な反応は、他の言語に存在する構造による強いバイアス効果があるということです。 白紙の状態の観点からこれにアプローチすると、想像できる行動が数十ありますが、TypeScriptには小さなサブセットしかありません。

メソッドに適用され、派生メソッドがスーパーhttps://github.com/Microsoft/TypeScript/issues/21388を介してそれを呼び出すように強制されたキーワードを簡単に想像でき

では、これを実装することを検討する適切な理由は何でしょうか？

フィードバックを見ると、次のような強力な考慮事項があります。

このJavaScriptライブラリの動作を適切に表現できません
私のコードはコンパイルされましたが、この（微妙な）エラーがあったため、実際にはコンパイルされるべきではありません
このコードの意図は、型システムによって適切に伝達されていません
finalはこれらにヒットしますが、「この関数を2回続けて呼び出すことはできません」または「このクラスの構築は次の非同期ティックまで実際には終了しません」という修飾子も同様です。 想像できるすべてのものが存在する必要はありません。

「実際にはサブクラス化できないクラスから継承しようとしたため、デバッグに何時間も費やした」などのフィードバックは見たことがありません。実際には想像できないため、「ワット」が正しくトリガーされると誰かが言っています。 修飾子が存在したとしても、クラスが最終的なものであるかどうかをライブラリが文書化しないため、実際には状況を改善しません。たとえば、fs.FSwatcher https://nodejs.org/api/fs.html#fs_class_fs_fswatcher final ？ ノードの作者でさえ知らないようです。 したがって、作成者が最終であることがわかっている場合は最終で十分ですが、それは関係なく文書化されます。最終がない場合は、どちらの方法でもわからないことが多いため、実際には何もわかりません。

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

ええ、議論は今とても拡散しています。 IntelliJ / webstormの問題に使用されるような、投票できるトラッカーでこれらの問題を確認したいと思います。 クラスやメソッドのfinalを見たい人の実際の数を取得します。

ファイナルはとても役に立ちます

抽象キーワードは、フィールドをオーバーライドする必要があることをプログラマーに思い出させるために使用されます。 オーバーライドしないように注意を促すキーワードも同様に役立ちます。

最終的なメソッドは、コードをより構造化および/または安全にするために重要になる可能性があります。

たとえば、サードパーティのプラグインをサポートするアプリケーションがあるとします。 すべてのプラグインに、作成する必要のあるメソッドのインターフェイスを実装し、操作の順序を制御し、操作間にフックを実装できるようにするいくつかの最終メソッドを含む抽象クラスを拡張するように強制できます。 このため、アプリケーションは個々のプラグインの詳細を認識する必要はなく、その内部状態の一部を認識している必要があります。

最終的なメソッドがないと、操作の順序を制御する関数に干渉する可能性があります。 アプリケーション内でバグ、エクスプロイト、またはその他の予期しない動作を引き起こす可能性があります。 ほとんどの状況には何らかの回避策がありますが、これらの回避策は複雑で反復的であり、場合によっては信頼性が低い可能性があります。 一方、finalメソッドは、メソッドが定義されている場合、それを1つの単純なソリューションにします。

また、この例はプラグインに固有ですが、他の状況にも適用できます。 （チームの新しい開発者、特定のロジックがスコープ外で実行されないようにする、コードの実行方法を標準化する、セキュリティベースのメソッドが変更されないようにするなど、すべてがこれから恩恵を受ける可能性があります）

@RyanCavanaugh finalが必要なrender（）の良い例はありますが、オープンクローズの原則については誰も言及していません（現在はSOLIDの一部として2位になっています）。
他の人が使用するフレームワークを作成するには、これが役立ちます。
そうでない場合、Typescriptでオープンクローズアプローチを採用するための好ましいアプローチは何ですか？

私はメソッドにfinalが大好きです（そして私は一般的にプロパティと宣言を想定しています）。 それは本当の問題を引き起こしています-人々は誤って物事を上書きし続け、その下に何かがあることに気づいていません...物事を壊します...

また、finalメソッドは非常に価値があると思います。他の人が指摘しているように、反対の議論はすべて最終クラスに焦点を当てているようです。 別の問題（＃9264）がありましたが、この問題がそれをカバーしているようであるため、クローズされましたが、実際にはそうではないと思います。 その問題を再度開くか、ここで適切に対処できますか？

私の状況は@ 0815foxに似てい

この機能を支持するコミュニティの圧倒的な支持にもかかわらず、TypeScript開発者によってまだ拒否されているのは困惑していると思います...

おそらくストップギャップは、TS-Docに標準を追加することであり、誰かが特定のクラスを継承したり、特定のメソッドをオーバーライドしたりしないようにアドバイスされます。 @final注釈などのように。

さて、「最終」に投票した他のすべての人が言ったことに何を追加すればよいのでしょうか...これが私の投票です。

同意しました。 確かに、関数型のプロパティのように扱う場合は、メソッドでreadonlyを使用できますが、この回避策はかなり混乱する可能性があります。 この問題のネイティブソリューションがあればいいのにと思います。

final 、特にfinal methodは、テンプレートパターンや他のデザインパターンで呼び出されるメソッドの順序を保証するメソッドのワークフローを制御することが多いため、型チェックでは重要だと思います。

finalは行く方法でなければなりません

ギャングは- （）このチケットがあるので、閉じ、および（b）は、私は新しいチケットを作成することを決めた議論は、単に最終的な方法に焦点を当てた「最後の方法」について誤解を招くタイトルを持っています。 うまくいけば、それは無視するのが難しくなり、ある程度の進歩を刺激するかもしれません。 そうそう、 https：//github.com/microsoft/TypeScript/issues/33446を参照して

@RyanCavanaugh

複雑さvsバリューバー

final何がそんなに複雑なのか、詳しく教えていただけますか？ 特にabstractなどのキーワードがすでに実装されており、そこから多くのロジック/コードを再利用できることを考えると、実装が最も簡単なキーワードの1つであるように私には思えます。

@vinayluzrao

ランダムな例として、現在、構成シグネチャを持つものから継承できると言っています。

// OK
declare const SomeParent: new() => { a: string };
class A extends SomeParent { }

明らかに、 finalクラスはnewです：

function make<T>(ctor: new() => T) {
  return ctor;
}
final class Done {
}
// No problem
const d = make(Done); // d: Done

しかし、今では矛盾があります。 newに対応できるものがありますが、 extends句を挿入することは合法ではありません。 したがって、1レベルの間接finalは

function subvertFinal(ctor: new() => any) {
  class Mwhahaah extends ctor {
    constructor() {
      super();
      console.log("I extended a final class! So much for 'types'!")
    }
  }
}
final class Done {
}
subvertFinal(Done);

これはすでに人々をabstractにつまずかせ、人々はabstractクラスには型チェックの目的で存在するが、実際には呼び出せないような暗黙の構成署名が必要であると常に主張しています。

参考までに、これらの議論で「複雑さ」と言うときの90％は、 TypeScriptのユーザーが経験する非常に複雑です）。 概念の複雑さは、より多くのより賢いエンジニアを製品に投入することで対処できるものではありません。 予期しない、または説明が難しい動作を引き起こす何かを言語に追加するたびに、それは言語のすべてのユーザーの精神的な負担になります。

メソッドのfinalが必要なのは、比較的定期的に、誰かがその下のメソッドを（知らないうちに）オーバーライドするため、コードが実行されず、非常に奇妙な方法で問題が発生し、人々が理由を知らないためです。多くの場合、デバッグには長い時間がかかります。

本当にそれを明確にする@RyanCavanaugh 、ありがとう。 しかし、私は考えを捨てたいと思います：あなたが与えた例の問題は、 newとextends間の強い結合が原因で発生しているようです、おそらくそれはより大きな問題です、 final自体ではありません。 なぜこの結合の決定がなされたのか、そしてこの時点でそれを元に戻すのはどれほど難しいのだろうか（まったく元に戻す必要があることを意味するわけではない）。

しかし、これがあまりにも接線的な議論であり、ここで議論することができないかどうかはわかりません。

これは私が遭遇した問題です。 このような単純なコードサンプルはコンパイルできません。
finalキーワードはそれを完全に解決します：

abstract class Parent {
    public abstract method(): this;
}

class Child extends Parent {
    public method(): this {
        return new Child();
    }
}

タイプ「子」はタイプ「これ」に割り当てることができません。
'Child'はタイプ 'this'の制約に割り当てることができますが、 'this'は制約 'Child'の異なるサブタイプでインスタンス化できます。

遊び場

これを再開できますか？ この機能が必要なことは明らかです

私たちはこの問題についてさまざまな会議で約12回議論し、そのたびに反対することを決定しました。 これを再開して13回目の議論をすることは、私たちの時間をうまく利用することではありません。

TypeScriptチームの決定に反対することはできますが、それは問題ありませんが、人々が反対する決定を再決定することはできません。 このリポジトリには、文字通り、このリポジトリが再び取り上げられる前に最初に検討する価値のある1000の提案があります。

@ nicky1038のコメントのような建設的な議論はここで大歓迎です。 このスレッドをロックする必要がないように、ニュース/再検討のリクエストについてこのスレッドに継続的にpingを送信しないようにお願いします。

メソッドのfinalの追加もサポートするためにここにいます。 サブクラスがオーバーライドできないようにする_init_という関数を持つ基本クラスがあります。 ファイナルは完璧な解決策になるでしょう。

メソッドにfinalキーワードを追加することもサポートしています。
今日では、それはオブジェクト指向プログラミングの標準です。

finalを追加することは私には理にかなっています。 特に、他の人が使用できるようにライブラリ/フレームワークを構築する場合、関数をオーバーライドするリスクさえ許容したくない場合。

間違いがなければ、 final追加すると、ジェネリックを操作するときに'myObj' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'MyClass'エラーが発生する手間を省くことができます。これは、 MyClass finalを作成できるため、そこで保証できるからです。他のサブタイプではありません。
100％確実ではありませんが、Javaでこの問題を解決する方法はそれだと思います。

同じものがあります。他の多くのパッケージがベースとして拡張できる、または拡張する必要がある角度のベースコンポーネントを作成しています。
ngOnChangesやangularのngOnInitのようなものがあり、基本クラスのみを実装する必要があり、サブクラスはこれらをオーバーライドするべきではありませんが、実際にはngOnInitReal（またはそれを呼び出すもの）を実装するため、それが呼び出されたときに完全に制御できます。ものによって。
これを制御することはできないので、文書化によってのみこれを行うことができます。 あるコンポーネントメーカーがこれを読まないと、そのコンポーネントが壊れたり、同じことをするためにベースから多くのコードをコピーする必要があります。

したがって、最終的な方法がなければ、堅実なAPI契約を結ぶことはできません。

誰かが言及しましたか

class Fancy {
    readonly secureFoo = (message: string) => {
        console.log(message);
    }
}

誰かが言及しましたか

class Fancy {
    readonly secureFoo = (message: string) => {
        console.log(message);
    }
}

これを行うことはできますが、いくつかの違いがあります。 たとえば、誰もが使用する関数を持つプロトタイプだけではなく、クラスの各インスタンスには関数の独自のコピーがあります。