Typescript: 部分クラス

モジュールにも「部分的」を採用し、ここで提起されたこの問題の解決に役立つと思います。

https://github.com/Microsoft/TypeScript/issues/447

@disshishkovおそらく拡張メソッドで十分です：＃9

これをどのような状況で使用したいのですか。また、既存のソリューションではどのようにそれを達成できませんか。

これは、自動生成されたファイルと同じタイプに寄与するユーザー編集ファイルがあるWinFormsタイプの編集シナリオをサポートするためにC＃で実装されたことに注意してください。 そのような状況がJavaScript / TypeScriptに当てはまるかどうかはわかりません。

一部のクラスには多くの行番号を含めることができますが、読みやすくするために、いくつかの個別のクラスに分割すると役立ちます。 ロジック（このロジックを別のクラスに移動できない場合）、可視性（プライベートおよびパブリック）など、さまざまなタイプで分割できます。 部分クラスの組み合わせで問題が発生する可能性がある場合（たとえば、同じメソッド/変数宣言と同じ2つの部分クラス）、コンパイラーはエラーを通知してスローする必要があります。

これは本当に魅力的ではありません。 クラスが非常に大きいため、サイズが非常に大きいために1つのファイルで快適に編集できない場合、それは非常に大きな設計上の臭いです（たとえば、http：//programmers.stackexchange.com/questions/157482のコメント）。 異なるタイプ/ロジック/可視性などによる分割は、IDEまたは単一のファイル内の編成によって処理できるものです。

クラスが大きすぎてナビゲートできない理由（ナビゲーションツールの方が優れている必要があるためですか？）、および言語がクラスを単に分割するのではなく、クラスを分解することをサポートできるより良い方法がある場合は、説明する価値があります。

個人的には「部分クラス」は存在すべきだと思いますが、モジュール同士が融合したように振る舞います。 私はモジュールを備えたシステムを持っていますが、インテリセンスはすべてのモジュールを（必要に応じて）認識しますが、それを含む実際のJSは必要な場合にのみロードされます。 必要なパーツだけをロードするだけで、クラスでも同じことができると思います。 また、関数を作成し、クラスを使用してさらに拡張したいと思っていました。 現在、これはモジュールでのみ実行できます。

部分クラスのユースケースは、生成されたプロキシクラスです。 たとえば、WebAPIまたはSignalRラッパー。 生成されたプロキシクラスをカスタムロジックで拡張できると本当に便利です。 特にモデルのクラスを生成するときは、APIから返されるモデルクラスにビジネスロジックを直接アタッチできると便利です。

+ 1kvantetore。

ユースケースは.netとまったく同じです。 クラスの一部が（この場合はAvroスキーマから）生成され、生成されたクラスを操作するためのヘルパーコードを追加する必要があります。

私はこの提案が好きです。 1つのファイルにまとめることができる「データ階層」を形成するクラスの属性/プロパティを、他のいくつかのファイルに分割できるメソッドから分離するために、部分的なクラスが必要です。 これにより、コードが一目でわかりやすくなり、理解しやすくなります。

私のデータ階層ファイル：

class A {
  x: number;
  y: number;
  z: number;
}

class B extends A {
  value: string;
  flag1: boolean;
  flag2: boolean;
}

クラスAのメソッドを含むファイル：

class A {
  constructor(x: number, y: number, z: number) {
    this.x = x;
    this.y = y;
    this.z = z;
  }
  method1(...) { ... }
  ...
  methodN(...) { ... }
}

クラスBのメソッドを含むファイル：

class B extends A {
  constructor(x: number, y: number, z: number, value: string) {
    super(x, y, z);
    this.value = value;
    this.flag1 = false;
    this.flag2 = false;
  }
  method1(...) { ... }
  ...
  methodN(...) { ... }
}

私から+1。 ttテンプレートを使用してTypescriptクラスを生成したいのですが、テンプレート生成によって置き換えられない別のファイルにそれらを追加します。

+1これは、拡張する必要のある自動生成されたクラスで本当に役立ちます

部分クラスは本当に素晴らしいですが、それを持っていることは意味がありません。 それはあなたがデザインの問題を抱えていることを示しました。 プログラミングの原則は、使用する言語に関係なく、単純な愚かさを保つことです（KISS）は、大きなクラスを小さなクラスに分割することです-1）スクリプトをクラスに分割して呼び出す（他のクラスもそれを呼び出すことができます）ホイールを再発明する代わりに、より小さなクラスも）、または2）分解して、抽象/インターフェース/継承/仮想などまたはポリモーフィズムに変換します。

すべてが入った車両があるとしましょう。 部分クラスは意味がなく、代わりにこれを行う方が理にかなっているところで、ここで複雑さとオーバーヘッドが発生します。 Engineクラス、Trannyクラス、Drivetrainクラス、Doorクラス、Tireクラスを個別のクラスとして作成し、スクリプトをそれらに移動します。これらを呼び出すと、Vehicleクラス内でVehicleを定義できます。 長いスクリプトとスクリプトの複雑さを軽減します。 Doorクラスによって簡略化できるDoorスクリプトがあちこちにあることに気付く可能性があります。 Interface / Abstract / Inheritance / Virtualを使用して、Vehicleクラスの一部のスクリプトのDoorクラス定義を変更できます。

また、この方法では開発時間が少なくなる可能性が高くなります。 私はかつて、多くの部分クラスを使用するASP.NET C＃ブログを持っていました。 部分的なクラスが多すぎるので苦労しましたが、どこにあるのかわかりません。 これは、プログラミングでGOTOロジックを扱うようなものです。 悪い悪い!! バグ修正のパッチを正常に作成することも、部分的なクラスの山に埋もれてしまったためにスクリプトをカスタマイズすることもできませんでした（名前が変更された表現もあります）。

私の心から1セントの考えとしてそれを言うだけです。

@ fletchsod-developer：一部の状況は継承によって適切に処理されますが、すべてではありません。 また、一部の開発者は部分的なクラスを誤用する可能性がありますが、すべてではありません。 部分クラスが非常に便利であると思う状況がいくつかありますが、それらが気に入らない場合は、使用する必要はありません。

@ jfrank14、@basaratにより上記の提案としては、＃9、あなたのために動作しないのでしょうか？

// File1.ts
class Dog { 
 ...
}

// File2.ts
extends class Dog {
  woof() { /* ... */ }
}

@NoelAbrahams 、ファイル内のfile1から定義にアクセスできますが、その逆はできませんか？ 包含順序に依存しない限り、それは私にとっては問題ありません。

皆さんがTSのC＃で部分クラスを検討することを本当に望んでいます...私にとって唯一の理由はコード生成です。これがC＃の部分クラスの背後にある主な理由です...私たちは現在多くのTSコード生成を行っています。ますます多くのことを行うことを期待しています...現在、「// 」に依存する必要があります

+ 1-自動生成されたクラスに機能を追加するためにこれを実際に使用できます。 これまでに考えたり読んだりできるエレガントなソリューションは他にありません...

+ 1-コードで生成されたクラス。 クライアントにシリアル化されたC＃/ Javaオブジェクト

生成されたクラスのマージにもこれが必要です！

これは、生成されたコードと生成されていないコードを簡単にマージできるようにするための非常に便利な機能です。

+1

+ 1-部分的に生成されたクラスにも必要です。この目的には必要のないかなりのコードを生成する継承よりもエレガントです。

+1

この制限に再び遭遇しました-この機能を追加してください！ ：+1：

+1

+1

+1

+1

人々はランダムに+1しますが、これは先に進みません。

これまでのユースケースは次のとおりです。

• 複数のファイルにまたがる非常に大きなクラスがあります。 @RyanCavanaughは、コードが複雑で、実装の複雑さを保証するには不十分であることが、設計上の大きな問題である可能性が高いことを示しました。
• それは彼らが好きです。
• 他の議論は、C＃がそれらを持っているということのようです。
• 他の議論は、他の言語から生成されたコードに関するものです。

2番目と3番目のユースケースは説得力がなく、4番目のユースケースでは、＃9の配信が非常に類似した要件、さらにはデコレータ（＃2249）をどのように満たさないかをある程度説明する必要があると思います。

＃9は同じことを達成し、さらに一般的になるように見えます（自分以外のクラスを拡張できるため）。 ただし、クラスのコンテンツを2つのファイルに入れて（おそらく1つは手書きで、もう1つはテンプレートによって生成されるため）、両方のファイルがクラスの重要なメンバーを同じ重要度で定義し、一方を必要としないと言うのは合理的かもしれません。ファイルは、他のクラスで定義されているクラスを「拡張」します。

これはほとんど実存的な違いですが、状況によっては一部の人にとってはおそらく重要です。

述べられている理由でクラスを部分的にしたくはありませんが、モジュールではそれは私見に意味があります。

https://github.com/Microsoft/TypeScript/issues/447

部分クラスは、ユースケースを特殊化するのに非常に役立ちます。 これは、OOPパターンの違反ではありませんが、コードド​​キュメントを配置する方法であり、次の機能を提供します。

1. クラス/タイプ定義を複数のファイルに分割する機能。 巨大なコードファイルの場合、それはmaintainability ++機能です。
2. コンパイラ/ビルドシステムがコンパイル時に条件付きリンケージを利用する機会。 アナロジーMSBuild、C＃での具体的なユースケース：DBML、デザイナークラス、https：//github.com/dotnet/corefx/pull/2045/filesなどのさらに凝ったもの。
3. 固有の保護。したがって、2人（またはそれ以上）の開発者がコードチェックイン中に互いに遭遇することはありません。 紛争解決が吹き飛ぶ！ :)
4. メインのパーシャルクラスにコードを生成してから、カスタムオーバーロード用に別のパーシャルを作成します。 完璧に動作します！

私はビジネスロジックとデータレイヤーを別々のクラスに分離することを信じており、私は主にこれらのレイヤーで静的メソッドを使用しています。 コードが増えて保守性が低下する可能性があるのか​​、私にはよくわかりません。

拡張メソッドはOOパターンの影響を受けるコア言語機能であり、コンパイル時に処理されますが、部分クラスは、コンパイル前の段階でステッチされるドキュメント/コードレイアウトを処理します。 部分クラス、抽象クラス、および拡張メソッドには類似性がありますが、明確な違いがあります。

：+1：無害な「部分クラス」をTypeScriptにもたらすため。

部分クラスの私のユースケースはコード生成です。私のチームは、あるファイルでクラスの一部を自動生成し、別のファイルでカスタムメソッドとプロパティを手動で追加できる必要があります。 このユースケースは選択した言語とは無関係であるため、 @ RyanCavanaughが「この種の状況がJavaScript / TypeScriptに適用されるかどうかわからない」理由は少し混乱しています。

デコレータも拡張メソッドも、部分クラスほどエレガントにコード生成の問題を解決することはなく、それぞれにかなりの複雑さがあります。

+1

+1

コード生成の目的で+1。

C＃環境では、C＃クラスのトランスパイラーをTypeScriptクラスに統合すると、クライアント側（別名TypeScriptクラス）が自動的に生成され、部分クラスが自動的に生成されるため、サーバー側とクライアント側の間でクラスの2つの異なる定義を保持する必要がなくなります。この問題が要求していることは、ネイティブTypeScriptで開発しながら、必要に応じてカスタマイズできるようにすることです。

コード生成シナリオの場合は+1

+1はコード生成に非常に役立ちます

コード生成に継承を使用してみませんか？

継承はより厄介で、より多くのオーバーヘッドがあります。

月、2015年8月10日には、10：09 AM Gorgi Kosevの[email protected]は書きました：

コード生成に継承を使用してみませんか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/563#issuecomment -129468291
。

継承は役に立たない名前の結合を作成します

継承は、次の理由でそれほど素晴らしいものではありません。

1. プロトタイプチェーンを不必要に深め、インスタンス化を遅くし、
   それはほとんどのアプリにとって大したことではありませんが、おそらくゲーム以外のすべてです。
2. 抽象化とオーバーライドが不足しているため、型安全性が失われるか、
   2つの間のキャストのようないくつかの厄介なパターンの必要性を導入します
   タイプ;
3. 基本クラスを持つことで、次のような考えが伝わるため、全体的に混乱しています。
   他のクラスで拡張できますが、codegenではめったにありません。

typescriptがcodegenをサポートするための部分的なクラスを持っていると言っているのではなく、
その部分的なクラスは、継承や
構成。

@JoshMcCullough JSの継承オーバーヘッドは最小限であり、部分クラスよりも

@ yahiko00ここで話しているのは、どのような「役に立たない名前の結合」ですか。 以下の2番目を取得するために必要なことを参照していますか（拡張クラスの名前をハードコーディングしています）？

@hdachev

1. いくつかのオーバーヘッドがありますが、それはごくわずかです-いくつかのマシン命令に直接変換することをしている場合にのみ目立ちます
2. 良い点-生成されたクラスを他の生成されたクラスから参照する必要がある場合、拡張クラスを取得しません。
3. それらのクラスは確かに拡張されることを意図しています-そうでなければ、それらを生成してそれで済ませることができますよね？

AFAIKこれはES7 +レーダーにはありませんね。 それは問題かもしれません...

いずれにせよ、既存のクラスのプロトタイプに余分なものを添付することは、JavaScriptでは非常に簡単であり、まったく珍しいことではないので、そのための構文を用意することをお勧めします...

TSでは簡単ですが、舞台裏のJSは2倍になります
生成されたすべてのデータに基本クラスを使用していた場合の「プロトアイピング」
オブジェクト。 あなたがたくさん持っていない限り、おそらく深刻なパフォーマンスへの影響はありません
データオブジェクトですが、「部分的
クラス」が可能です。

11:03 Gorgiで月、2015年8月10日にはKosev [email protected]
書きました：

@JoshMcCulloughhttps ：//github.com/JoshMcCullough継承オーバーヘッド
JSでは最小限であり、部分クラスよりも厄介であることがわかりません。
それらを使用すると、クラスを10個のファイルに分割して、追跡することができます。
いたるところにメソッド。

@ yahiko00https ：//github.com/yahiko00どんな「ダメな名前」
カップリング」はここで話しているのですか？あなたはあなたが必要とするものを参照していますか？
以下の2番目を取得するにはどうすればよいですか（拡張クラスの名前をハードコードします）？

クラスMyClassはGeneratedMyClassを拡張します{...}

@hdachev https://github.com/hdachev

1.1。

オーバーヘッドはありますが、ごくわずかです。
https://jsperf.com/prototype-chain-vs-direct-calls-目立つだけ
いくつかのマシンに直接変換されることをしている場合
手順
2.2。

良い点-あなたがしなければならないときにあなたは拡張クラスを取得しません
生成されたクラスを他の生成されたクラスから参照します。
3.3。

それらのクラスは確かに拡張されることを意図しています-そうでなければあなたはそうすることができます
それらを生成し、それで完了しますよね？

AFAIKこれはES7 +レーダーにはありませんね。

いずれにせよ、既存のクラスのプロトタイプに余分なものを添付する
JavaScriptでは非常に些細なことであり、まったく珍しいことではないので、
そのための構文を用意することをお勧めします...

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/563#issuecomment -129483174
。

@ Davidhanson90そのファイルにはクラスがあり

正しいスレッドに投稿します。 https://github.com/Microsoft/TypeScript/issues/447

+1

+1

+100

+1

+1

コード生成の場合は+1。
私はangularjsとwebapiを使い始めており、基本的にc＃オブジェクトとサービスから自動JS定義を作成するツールを作成したいと考えています。 次に、「足場」のJS定義を編集せずに、これらのクラスを拡張できるようにしたいと思います。 他の何人かの人々がこれを要求しているのを見ました、そして私達が同様のユースケースを持っているようです。

コード生成の+1

コード生成の+ 1、angularには多くの定型コードがあり、すでに多くの生成を行っていますが、部分クラスを使用すると、さらに多くのことができるようになります。

コード生成のためにもう一度+1します。 別のファイルでクラスを拡張しようとすると、せいぜい面倒です。

@RyanCavanaugh 、これを「+1」モードから抜け出し、生産的な方向に

-1次の構文はミックスインに適しています：＃2919

部分クラスとミックスインの両方を使用できない理由がわかりません。 2つのまったく関係のない機能。

+1

これはコードが生成されるときに便利ですが、生成されたコードに何かを追加するためにコードを変更する必要はありません。

+1

これらのユースケースの両方を満たす必要がある提案があります。

1. 独自のクラスのメソッドをさまざまな場所に記述したいとします。
2. ビルトインなど、他の誰かのクラスに新しいメソッドを追加したいとします。

（2）の場合、通常は::演算子を使用して中置構文を取得します。

ただし、古いクラスを新しいインターフェイスの一部にしたい場合、または動的にディスパッチしたい場合は、実際にプロトタイプを変更する必要があります。

interface ITimes {
    times(n: number): number
}

Array implements ITimes {
    times(n: number): number {
        return this.length * n
    }
}

// The compiler should check that all methods of ITimes and IOther are implemented.
Number implements ITimes, IOther {
    times(n: number): number {
        return this * n
    }

    other(): void {}
}

// The old types should typecheck with the new interface.
const x: ITimes = true ? [] : 0
x.times(3)

// The interface list can be empty. This essentially gives you partial classes.
MyClass implements {
    anotherMethod(): void {}
}

（この例では、文字列メソッド名を使用していますが、これらは組み込み型であるため、型チェックが可能になれば、シンボルを使用する方が適切です。）

これが真の部分クラスよりも優れている点は、クラスの定義が1つであり、他の場所ではそれを拡張するだけであるということです。 これは、クラスをインポートするための明確な場所があり、JSへの翻訳を容易にすることを意味します。

：+1：部分的なクラスも見たいです。

この機能のステータスは何ですか？

このユースケースの例：

クラスSetを定義するMathパッケージがあり、メソッドSet#add 、 'Set＃remove'

// math.ts
export partial class Set {
  add(){}
  remove(){}
}

クラスRelationとTupleを定義するオプションの重いRelationalパッケージがあります。

このRelationalパッケージは、 Set#productメソッドも追加します。

// relational.ts
///<reference path="./../math/tsd.d.ts"/>
partial class Set {
  product(){}
}

export class Relation(){}
export class Tuple(){}

部分的なクラスを使用すると、より柔軟な方法でクラスを作成できます。 重いrelationalパッケージを使用したくない場合でも、基本的なセット機能を使用できます。 他のpartialクラスは入ってきて、クラスに機能を追加するだけです。

この場合、パーシャルを使用せずに優れたAPIを使用できるようにするために、頭を悩ませています。

私が持って来ることができるのは、いくつかのリポジトリパターンだけです。

// Without partials

// base

export class Base {
    static registerOperation(opName, method){
        this.prototype[opName] = method;
    }
    operation(name, ...args){
        return this[name].apply(this, args);
    }
}

// math.ts
import {Base} from './base';
class Set extends Base{
    // Define the methods here
    add(){}
    remove(){}
}

// Or here
Set.registerOperation("add", function(...){});
Set.registerOperation("remove", function(...){});

// relational.ts
import {Set} from './../math/math';

Set.registerOperation("product", function(...){});

// app.ts

import {Set} from 'math';

var set = new Set();
set.add // compiler error
set.remove // compiler error
set.product // compiler error

// have to use something like
set.operation("add", args);
// or
(<any>set).add(arg);

+1私はt4を使用してWebApiを介してクラスとプロキシを生成しています。 自動生成はtypescriptで広く使用されていると思います。自動生成に関しては、部分的なクラスが必要です。

特にReactで同じクラスの側面を分割するのに最適です
+1

+1コード生成と、クライアント固有の属性を持つ純粋な再利用可能なデータオブジェクトの場合は、クラスで定義するのに適しているが、別のソースコードで維持されるような検証のための「十分な分離」。

部分クラスのコード生成には+1を使用し、これらのクラスの追加メンバーを個別のファイルにハンドコードします。

+1

+1私はjsapiサービスにメソッドの大規模なベースを持っています、それはそれらをファイルに分割するのが最善でしょう、それはそれぞれのメソッドを理解するのを簡単にします。

fb (facebook)やgq (google analytics)などのAPIサービスでは、開発全体で使用できる1つのグローバルクラスまたはオブジェクトが提供されます。

+1

この機能は私たちにとっても大きなプラスになります。

私たちは、あらゆるタイプのクライアントが接続し、それを介してサーバーと通信できるミドルウェアを開発しました。

サーバーによって公開されているものに基づいて、クライアントコードの一部を生成します。

これまでのところ、すべてが大丈夫だった。 しかし今、私たちはオブジェクトの異種コレクションを転送できるようにしたいと思っています（ただし同じ基本クラスを使用します）。 転送されるオブジェクトは、サーバーAPIに基づいて生成されたコードの一部です。

この場合、継承の力を利用できるようにするためには、抽象メソッドが鍵となります。 しかし、私たちの開発者は生成されたコードにメソッドを追加しません、私は誰もが理由を知っていると思います;）

私が理解している限り（私はC＃開発者です）、ここで提案されているソリューション（https://github.com/Microsoft/TypeScript/issues/9）ではそれができません。

したがって、部分的なクラスは私たちにとって完璧です。 クラスを部分的に生成し、開発者がロジックやメソッドを追加する必要がある場合は、必要に応じて他の部分を作成するだけで済みます。

+1

+1はコード生成に非常に役立ちます

モジュールの拡張は、基本的に特定の機能としてのこれの必要性を否定するのだろうか。

生成されたクラスがある場合は、次のようなことができるはずです...

import {MyClass} from "./MyClass.generated"

MyClass.prototype.partialMethod1 = function() {
  return true;
}
MyClass.prototype.partialMethod2 = function(abc: string) {
  this.doSomething(abc);
}

declare module './MyClass.generated' {
  interface MyClass {
    partialMethod1(): boolean;
    partialMethod2(abc: string): void;
  }
}

@disshishkovこれは

Elephant-Vesselに同意します。 部分クラスの手動で作成されたパーツは、生成されたパーツから可能な限り緩く結合する必要があります（TSの設計時）。

@ david-driscollによる提案は、多くの場合に機能します。 しかし、私が知る限り、プロトタイプは内部変数にアクセスできません。 これにより、クラスのコア部分を生成してからカスタムコードでそれらを拡張するコード生成コンテキストでのこのアプローチの有用性が制限されます。

+1

@ david-driscollは、この機能を脱糖するための優れた方法のように見えます。 （プライベート/保護されたプロパティにアクセスする機能を追加する必要があります）。 複数の部分的なクラス宣言で何が起こるのだろうか？ それらの相互の可視性はどうなるでしょうか？

++ 1自動生成されたモデルを拡張しようとすると、部分的な欠如が本当に私を傷つけています。

ここでのスコープの唯一のものは基本的に@ david-driscollが提案したものだと思います-新しいメソッド（プロトタイプに配置される）と新しい_non-initialized_プロパティ（codegenを持たない）を宣言できますが、新しい初期化されたプロパティは宣言できません（これらはコンストラクタcodegenに副作用があるため）。

反対票を投じて、私のフランス語を許してください。部分クラスは、OOPで避けられない神のクラスを複数のファイルにチャンクして、管理しやすくするという愚かな試みです（ただし、神のクラスです）。

OOPではあなたの人々に未来はありません（そこにいて、私が話していることを知っています）

FPに来ると、Cookieと、単一のクラスなしでプログラムを作成する方法があり、このようになります。

したがって、基本的には、 interface A { method(): void } A.prototype.method = function() { };介してこれを許可します。 これを砂糖に成文化することは、まさにそれが理にかなっています。

バイクシェッドすることの1つは、キーワードpartialです。 簡単な歴史的ビネット：C＃では、 partial classは元々 extension class （1つを除くすべての宣言）になりますが、どの宣言がextensionと、どの宣言が非拡張宣言になるか。 代わりに、_all_クラスに配置する必要のある修飾子partialがあります。

これはTypeScriptの場合ではありません。 むしろ反対です。 ここでは、1つのクラス（「_primary_宣言」と呼びましょう）のみがコンストラクター/初期化されたメンバーフィールドを持つことができます。 一次宣言は新しい修飾子を取得しません。 他のすべての宣言（「_extension_宣言」と呼びましょう）には、静的、メソッド、および初期化されていないフィールドのみが含まれる場合があり、プライマリではないことを示すためにいくつかの修飾子を付ける必要があります。

現在の最良の推測は

class Foo {
  x = 6; // only legal to initialize here
  constructor() { } // only legal to have constructor here
  someMethod() { }
}

// vvvvvvvvv thoughts?
   extension class Foo {
     someOtherMethod() {
     }
   }

：sparkles ：： bike ：： house ：： sparkles：

バイクシェディングであろうとなかろうと、これは、将来のECMAScript標準に干渉する可能性があるために離れた＃311のようにひどい音に聞こえます。 なぜこれを検討する価値があるのに、適切なミックスインサポートがそうではないのですか？

キーワードextensionすると、拡張メソッドと競合し

@kitsonkミックスインの提案にはもっと多くの未解決の質問があると思います。 ここでの部分的なクラス提案は、TypeScriptですでに許可されているものを体系化したものであり、構文糖衣構文が含まれています（この機能は、文字通り、既存のものへの構文の再マッピングとして実行できます）。

@ Elephant-Vessel部分クラスが発生した場合、拡張メソッドは発生していないと思います。 クラスは、制約を考慮して拡張メソッドが意味をなす唯一の場所であり、提案されたES7 +バインド演算子は、拡張のような構文で靴べらをするためのより良い方法です。

@RyanCavanaugh ：私には、1つのクラスがプライマリで、他のクラスがプライマリでないことを要求するのは少し制約があるようです。 1つのファイルにクラスのすべてのメソッドが含まれ、もう1つのファイルにすべてのプロパティが含まれるようにコードをパーティション分割する場合、どちらも明らかにプライマリに見えません。なぜ選択を強制する必要があるのでしょうか。 重要度がすべて同じで、コンパイラーによってマージされるパーシャルがある方がクリーンではありませんか？

@RyanCavanaugh ... c＃とまったく同じ方法で実行します...コード生成に最適です...これは、c＃で解決する機能の主な問題であると思います...私の記憶はあいまいですが...問題は発生していません。何年も前から存在しており、バトルテストが行​​われています...

部分/拡張クラスでフィールドを初期化できない場合は、C＃で部分メソッドのよう

public partial class MyGeneratedClass
 {
     partial void Initialize();
     public constructor()
     {
          //...
         this.Initialize();
    }
 }

 public partial class MyGeneratedClass
 {
     partial void Initialize()  { //... }
 }

サードパーティのクラスを部分化/拡張できる必要性は、 partial/extends一般的にオプションにすることで非常に簡単に（？）解決できますが、部分メソッドの使用には必須です。

これは、私たちがここで望んでいるコンセプトに、きちんとした表現力と操作力をもたらすことができると思います。

ミックスインを探している人。

オブジェクトがプロポーザルを

function enableBeingPositioned<a>(
   // hypothetical syntax
   something: a /* <-- before type */ => a & { x: number; y: number; } /* <-- after type */
): void { 
   something.x = 0;
   something.y = 0;
}
let value = {};
value.x; // <-- should not typecheck
enableBeingPositioned(value);
value.x; // <-- should typecheck

Javaなどの言語は、部分的なクラス/構造体を提供していません。 これはC＃のニッチな機能です。 ここに行くには、C＃の「部分クラス/構造体」の概念を完全に模倣するのが最善の方法です。
コンパイル前のステップで、TSコンパイラが最初に実行できることは、メモリ内の部分的なコードブロックをステッチしてから、通常のコンパイルパイプラインルートに移動することです。 これは、TypeScriptの部分クラス機能のv1.0.0-preview1.0000の資格を得るのに十分すぎるほどです。
C＃が提供しているもの以外のものは、機能が進化してトライアル/プレビューよりも長生きするときに、後のバージョンで導入できるものです。 コーナーケースと同様の種類のあいまいなものは、一度に1つずつ個別に議論することができ、後でフィット＆フィニッシュについて心配することができます... IMO。

また、部分クラスと拡張クラスの両方をc＃とまったく同じ方法で実行することに同意します。
構文とセマンティクスの観点からは、どちらも機能するのが最善の方法ですか？
それぞれのユースケースに非常に適しています。 部分クラスは
生成されたコードの使いやすさ。 拡張方法により、使いやすさが向上します
インターフェイス、指定されたジェネリック、および3番目に動作する静的メソッドの
パーティータイプ。 どちらも本当にかっこいいですが、そうではないことを覚えておいてください
同じ機能ですが、上記の構文が提案されているため、ここでこれを言います。

拡張メソッドを使用すると、これを実行できます（フォーマットの欠如については、
電話での入力）：

MyType []を拡張する{
somethingSpecificToMyType（）{...}
}

WeirdThirdPartyDatastructureを拡張する{{
こっちも一緒（） { ... }
}

アンダースコアのようなライブラリを使用できるようになるなど、とりわけ
がらくたなしで、これは基本的にの構文上の利点を享受することを意味します
実際にそれらを汚染することなく組み込み型を拡張します。

とても簡単です-2つを同じものとして扱うことはできません、それらは両方とも非常に
かっこいいですが、同じではありません。 私は個人的に両方を私たちに入れたいです
言語。

ちなみに、ちなみに、多くの人が
コード生成とそれが場所がないことを皆に説明する準備ができています
同じことを達成するためのより慣用的な方法があるため、JavaScriptで。
コード生成が非常に役立つ2つの方法があります
私が今取り組んでいるようなプロジェクト。

• ゲームなどのパフォーマンスに敏感なプロジェクトでは、
  便利な作業でCPU予算を最大限に活用するためのすべて、codegenは1トンを助けます
  推論が簡単で、高度に最適化できるコードを生成する
  /非常にうまく機能する単形コード。 たとえば、
  エンティティ/コンポーネントゲームエンジン、生成されたコードはたくさんのものを助けることができます
  コンポーネントをくっつけるための非常に高速なボイラープレートコードのように、イベント
  発送等
• 大企業のアプリでは、生成されたコードは極端なマイレージを引き出すのに役立ちます
  型システム、例えば非常に具体的なメソッドを放出することによる
  コンパイル時間を最大化するデータベースクエリなどの署名
  チェックし、リファクタリングを大幅に支援し、デバッグを大幅に簡素化します
  非常に単純なオーケストレーションコードをステップスルーできるためです。
• 大きな問題は、コンポーネントの同期を維持している場合です。
  多言語環境、例えばメッセージングに関連するもの
  プロトコルバッファ、または単にjsonメッセージインターフェイスなどのように。

部分的なものを疑問に思っている人のための別のサイドノードとして
クラスは、生成された部分を保持することの価値であるcodegenと関係があります
クラスの別のファイルへの変換は、ソース管理要件に由来します-
生成されたものは通常、急速に変化するビルドアーティファクトであり、
リポジトリにコミットしたくない。

私は、C＃と同じように、この概念のよく知られた、試行錯誤されたモデルに応じてこれを実装するというアイデアが好きです。 「模倣」にはいくつかの否定的な意味合いがありますが、インテリジェントに実行すると大きな価値があります。 一方、「インテリジェント」-その一部はさまざまな状況と制限を認識することであるため、TypeScriptのパーシャルがC＃のパーシャルと正確に一致しない場合は抗議しません。

@ Elephant-Vessel、C＃パーシャルの同じコピーである必要はないことに同意します。一般的なデザインは、C＃パーシャルから最大限のインスピレーションを得ながら、TypeScript / JavaScriptフレーバーを中心に最初に作成してレイアウトできます。 私の提案は、最初のステップとして「 partialキーワードの登録」と「パーシャルのステッチ」を使用し、それを実験/プレビュー機能として出荷することです（したがって、消費者は本番コードでそれに依存し始めません）バットから）。 後で、コミュニティの反応に基づいて、製品の準備が整い、RTMが実行されるまで機能を進化させます。 あらゆる種類のトリッキーな落とし穴やシナリオを事前に心配している場合、おそらくそれは問題をさらに遅らせるでしょう。

+ 1-生成されたオブジェクトを拡張および保守します。

生成されたコードを維持するための+1

ポリフィルを作成し、大きなクラスを分割しました。

クラスをインターフェースとして定義します。

export class C {
  constructor() {
  }
}
export interface C {
  m(): void;
}

クラスメンバーを実装します。

export default class extends C {
  m(): void {
  }
}

実装をマージします。

import {C} from './core';
import m from './member/m';

compose(C, m);
export {C}

import {assign} from './assign';
import {concat} from './concat';

export function compose<T extends new (...args: any[]) => any>(target: T, ...sources: T[]): T {
  return concat([target], sources)
    .reduce((b, d) => {
      void assign(b.prototype, d.prototype);
      for (const p in d) if (d.hasOwnProperty(p)) b[p] = d[p];
      return b;
    });
}

https://github.com/falsandtru/spica/commit/a6ff30da5319db5f25f703a29da48fc0f7dbe2fe

これは1つの特定の理由でひどい考えだと思います。それは、グローバル、アンビエント、外部、名前空間、および脆弱な宣言順序に依存する継承の問題に対するすでに複雑なルールを大幅に悪化させるでしょう。 これはC＃ではなく、名前解決とメンバー宣言は大きく異なります。

おそらく、クラスの代わりにオブジェクトまたは名前空間を使用します。本当にこれを行う必要がある場合は、モジュールパターンを明らかにします。 それ以外の場合は、クラスが大きすぎる可能性があります。

また、デコレータを使用して、生成されたコードと手書きのコードの間の関連付けを実装できます。

他に解決策はありますか？

これもTSに追加してほしいです

コード生成の目的で+1（追加の部分クラス定義を含むWCFサービス参照からのDTO）

コード生成の目的で+1。 私のユースケースは次のとおりです。 render()関数がreact-templatesを介して外部で生成されるReactコンポーネントがあります。

partialクラスを使用すると、このような関数とメインクラス（ Component ）のタイプチェックを行うことができます。 部分クラスがなければ、私にできることは、関数をメインクラスにバインドし、最高のものを期待することだけです。

次のTS2.0では、コード生成の一部のケースがthisタイプの機能でカバーされる可能性があると考えていました。

たとえば、前に説明した場合ではなく、

partial class MyComponent extends React.Component<any,any> {
    render() {
        ...
    }
}

私は書くことができます

function render<this extends MyComponent>()
        ...
}
MyComponent.prototype.render = render;

+1開発者として、複数のテンプレートが複数のファイルに分散した同じクラスを生成/変更できるように、部分的なクラスが必要です。

私のコメントは、ミックスインではなく、部分的なクラスに関するものでした。 この2つは根本的に異なります。 部分クラスは物理コードを分割することであり、ミックスインは論理動作を再利用可能な特性に分割することであり、タイプレベルと値レベルの両方で他のオブジェクトを強化します。
TypeScriptにとって部分クラスは良い考えではないと思います。 一方、ミックスインは良いアイデアであり、@ aleksey-bykovが指摘しているように、TypeScriptの型システムとJavaScriptイディオムの両方で表現力を高め、メッシュを非常にうまくメッシュ化できます。

@wendellmは、ESモジュールが物理的であることを考えると、これを行うためのクリーンな方法を考えることができます。 部分クラスはうまく機能し、モジュールが物理的ではなく論理的であるC＃のような言語で非常に意味があります。 CLRの観点からは、名前空間は存在しません。クラス名にドットを含めることができるだけです（@ahejlsbergへのインタビューを参照）

+1部分クラスが必要です！

インターフェイスを拡張できますか？ インターフェイスには、Swiftのように、いくつかの実装された関数を含めることもできます。

interface Rect {
    x: number
    y: number
}

extension Rect {
    area() => this.x * this.y
}

Swiftバージョン：

protocol Rect {
    var x: Float {get}
    var y: Float {get}
}
extension Rect {
    func area() -> Float {
        return self.x * self.y
    }
}

+1

コード生成と部分クラスは密接に関連しています。

継承は、本質的に栄光の#includeディレクティブであるものに対する不十分な解決策です。

Angular2を例にとってみましょう。 親クラスからメタデータを

@tsvetomirは、TypeScriptの問題ではなくAngularの問題です。

継承は、本質的に栄光に満ちた#includeディレクティブに対する不十分な解決策です

はい、継承は不十分な解決策ですが、問題はそもそもクラスを使用することです。 彼らは彼らの場所を持っていますが、それは非常に限られています。 JavaScriptクラスは、他の言語のクラスと比較してかなり弱く、表現力がありません。

Typescriptは「Angular」言語ではありません...

21:46に2016年7月23日、上、Aluanハダッド< [email protected] [email protected] >書きました：

@tsvet omirhttps：//github.com/tsvetomirこれはTypeScriptの問題ではなくAngularの問題です。

継承は、本質的に栄光に満ちた#includeディレクティブに対する不十分な解決策です

はい、継承は不十分な解決策ですが、問題はそもそもクラスを使用することです。 彼らは彼らの場所を持っていますが、それは非常に限られています。 JavaScriptクラスは、他の言語のクラスと比較してかなり弱く、表現力がありません。

あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、Gi tHubhttps：//github.com/Microsoft/TypeScript/issues/563#issuecomment -234753589で表示するか、読み取りをミュートします

私はこの問題をAngular固有のものとは決して考えていません。 これは、部分的なクラスが役立つ可能性がある特定のケースです。

このリクエストは、C＃の過去の経験と使い慣れた機能の欠如に起因しています。 TypeScriptは.NETから距離を置くないため、比較は避けられ

このリクエストは、C＃の過去の経験と使い慣れた機能の欠如に起因しています。 TypeScriptは.NETから距離を置く努力をしないため、比較は避けられません。 ユーザーは、何らかの形の機能の同等性を期待しています。

@tsvetomirは、長年の.NET開発者として、そして情熱的なC＃プログラマーとして、根本的に同意しません。

あなたが引用した記事は信頼できるものではなく、TypeScriptチームの公式資料を反映していません。

さらに、 @ ahejlsbergが多数の講演、インタビュー、投稿で述べたTypeScriptの設計哲学と直接矛盾します。

さらに、引用された記事の視点は、TypeScriptの性質に関する根本的な誤解を反映しています。
皮肉なことに、C＃がTypeScriptと共通しているのは、実際にはJavaScriptと同じです。
これらの共通点はクラスベースのプログラミングではなく、クロージャや高階関数などの構成概念です。

C＃であろうとなかろうと、TypeScriptがJavascriptのプロトタイプ機能に近づくのに役立つ部分的なクラスが必要です。

@ yahiko00
TypeScriptには、JavaScriptのプロトタイプ機能がすべて含まれています。
スーパーセットです。

TypeScriptの部分クラスの概念には、次のようないくつかの問題があります。

1. C＃とは異なり、TypeScript（JavaScript）クラス定義は宣言型ではなく命令型です。 それらは宣言的に見えますが、そうではありません。 これは、それらが決定論的な実行順序に依存することを意味します。
2. ECMAScriptモジュールシステムは、論理コードユニットではなく物理コードユニットのインポートに基づいています。
   たとえば、私が持っているとしましょう

_app / my-class-part-1.ts_

TypeScript export partial class MyClass { firstName = "John"; lastName = "Smith"; }

と
_app / my-class-part-2.ts_

TypeScript export partial class MyClass { fullName = this.firstName + ' ' + this.lastName; }

このクラスをインポートするにはどうすればよいですか？ どちらのモジュールからもインポートできないので、TypeScriptで仮想的な抽象化を想像してみましょう。
_app / main.ts_

TypeScript import { MyClass } from './my-class';

これはどういう意味ですか？ TypeScriptコンパイラが_app / my-class-part-1.ts_を_app / my-class-part-2.ts_の前にロードする必要があると推測できたとしても、個々のパーツのインポートを無効にすることも、保証することもできません。それらは、RequireJSなどの非同期モジュールローダーまたは最終的にブラウザーに実装されるものによって正しい順序でインポートされます。

部分クラスの概念全体は、基本的にECMAScriptモジュールシステムと対立しています。

更新：任意に複雑な依存関係の推論を実行し、非常に奇妙なJavaScriptを出力する必要があります。

TypeScriptには、JavaScriptのプロトタイプ機能がすべて含まれています。
スーパーセットです。

もっと自分を表現すべきだった。 もちろん、TypeScriptがJavaScriptのスーパーセットであることは誰もが知っています。 しかし、部分クラスはTypeScriptクラスがJSプロトタイプに近づくのに役立つと言いたかったのです。 今のところ、「静的」で拡張不可能なクラスを使用できますが、プロトタイプアプローチでは、クラスのような関数を拡張できます。

部分的なクラスをインポートすると、私が同意する現在のES6構文が拡張されます。 私たちはこのようなものを想像することができます：

import { MyClass } from ['app/my-class-part-1', 'app/my-class-part-2'];

TypeScriptクラスはECMAScriptクラスに基づいているため、ECMAScriptクラスの表現力の欠如に悩まされています。 関数、モジュール、「名前空間」、またはプレーンオブジェクトを使用して、必要なことを実行することを検討してください。

関数は、クラスの概念で避けたいものです。
モジュールまたは名前空間は単純な拡張性をもたらし、TypeScriptのクラスと同じ表現力を持っていません。 また、名前空間またはモジュールをインスタンス化することはできません。 それらはクラスと同じ目的を果たしません。

@aluanhaddadモジュールに関してあなたが何を意味するのかexport partial classに許可し、残りのファイルにはpartial class定義のみを含めることです。 エクスポートした場所からインポートします。 あなたの例から：

_app / my-class.ts_

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

_app / my-class.part.ts_

partial class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

_app / main.ts_

import { MyClass } from './my-class';

不足しているのは、コンパイラにパーツの場所を知らせるための構文です。 これは、すべてのファイルを一度に処理するC＃の問題ではありません。 これは、宣言のマージに使用される構文のように、特別な構文である可能性があります。

部分クラスで任意の定義を許可する必要はありません。 たとえば、メソッド、プロパティ、コンストラクターにのみ制限できます。 これにより、実行順序が重要でなくなり、メンバーが重複している場合にコンパイラーがエラーをスローできるようになります。

モジュール拡張がこれらのシナリオに無効である理由がわかりません。 Rxjs5では非常にうまく機能しました。

基本クラスを作成し、コード生成を使用して、基本クラスの上に必要なすべての拡張メソッドを生成するだけです。 生成されたコードがきれいであるかどうかは関係ありません。人間がそれを書くことは想定されていません。

部分クラスの完全な代替品ですか？ そうではないと思いますが、JavaScriptが必要だとECMAScriptが判断しない限り、部分的なクラスが発生することはありません。 部分クラスが外部モジュール間でどのようにリンクされているかについてのセマンティクスだけでも、頭が痛くなります。

@ david-driscollをさらに改善するために、追加されたメソッドでthis:引数を宣言して、より強力な型チェックを行うことができます。

モジュール拡張の引用例では：

// observable.ts stays the same
// map.ts
import { Observable } from "./observable";
declare module "./observable" {
    interface Observable<T> {
        map<U>(f: (x: T) => U): Observable<U>;
    }
}
Observable.prototype.map = function (this: Observable, f) {
    // here "this" has the shape of the "Observable" class
}

うん。 Rxjsは2.0の機能であり、2.0はまだリリースされていないため、まだ静かに使用していません。 後でヒットリストに載っています。

モジュールに関してあなたが何を意味するのかわかります。 考えられる解決策は、ファイルの1つだけに部分クラスのエクスポートを許可し、残りのファイルには部分クラス定義のみを含めることです。 エクスポートした場所からインポートします。 あなたの例から：

_app / my-class.ts_

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

app / my-class.part.ts

partial class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

私は構文の概念が好きですが、問題は、一種の暗黙的なモジュールとして消費され、スクリプトのように見え、特定の方法でロードする必要がある新しい_種類のソースファイルを導入したことです。

不足しているのは、コンパイラにパーツの場所を知らせるための構文です。 これは、すべてのファイルを一度に処理するC＃の問題ではありません。 これは、宣言のマージに使用される構文として、特別な構文である可能性があります。

宣言のマージは、ソースファイルではなく、_declarations_に対して機能します。

部分クラスで任意の定義を許可する必要はありません。 たとえば、メソッド、プロパティ、コンストラクターにのみ制限できます。 これにより、実行順序が重要でなくなり、メンバーが重複している場合にコンパイラーがエラーをスローできるようになります。

これらはすべて、一般的に順序に依存します。

編集：つまり、それらを定義するとクラスが変更されます。

おそらく誰かがすでにこれについて言及していますが、別の便利なケースは、コードジェネレーターからクラスの一部を生成し、実装に直接手動でコードを追加したい場合です。
ミキシングや派生クラスは本当にしたくありません。
それはまだ1つのクラスです-一部だけが自動的に生成され、他の部分は手動で生成されます。

ところで：誰かがC＃クラスからTSタイプを生成する必要がある場合は、 TypeScriptBuilderを確認できます

これを検討していただきありがとうございます！

TypeScriptBuilderを試してみます;）

私のおすすめ...

コンパイラがすべての部分を見つけようとしなかった場合はどうなりますか？ 他の部品をインポートしてすべてを制御する必要がある場合はどうなりますか？

/MyClass.partial.ts

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

MyClass.ts

// v- this would NOT throw an error because the definition is marked as partial
import { MyClass } from "./MyClass.partial";

export class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

それで...

1. MyClassを使用したい場合は、 MyClass.tsからインポートする必要があります
2. コンパイルすると、 MyClass.partial.tsは、前に示したようにMyClass.prototypeを拡張するJavaScriptを生成します。 ただし、拡張するプロトタイプを受け取る関数をエクスポートします。
3. MyClass.partial.tsは、 MyClassが定義され、その拡張関数が呼び出された後、 MyClassにインポートされます。

ちなみに...コンパイルされたコードを直接生成することを妨げるものは何もありません。 しかし、私はTypescriptの素晴らしさをすべて失います。

@svalloryこれは間違いなく正しいアプローチだと思います。 具体的には、生成されたコードが拡張を引き起こす関数をエクスポートすると言うので、関数は必要な決定論的な順序で呼び出すことができるため、非同期インポートでも機能します。

より一般的には、それが参照された問題を忘れています。クラスプロトタイプへの割り当てがクラスの形状に影響を与えた場合、多くの利点があります。 これにより、ミックスインライブラリが改善され、デコレータがはるかに便利になり、一般に垂直階層が少なくなります。

コンパイラがこれらすべてを追跡するのは難しいかもしれませんが、あなたが提案するように明示的にすることでおそらく動作させることができます。

これは型システムの拡張であり、部分クラスのユースケースはその拡張から外れます。

私は次のようにそれをしました：

私は次のようにそれをしました：
 file1 。 NS
インターフェイスifoo {
 a （ ） ： void ;
 }
クラスfooはifoo {を実装します
 a （ ） { / *何かをする* / }
 }
 file2 。 NS
 /// <reference path = "file1.ts" /> //不要
インターフェイスifoo {
 b （ ） ： void ;
 }
 foo 。 プロトタイプ。 b = （ ） = > { / *何かをする* / }
 file3 。 NS
 /// <reference path = "file1.ts" /> //不要
インターフェイスifoo {
 c （ ） ： void ;
 }
 （<ifoo> FOO。プロトタイプ）。 c = （ ） = > { / *何かをする* / }
消費者。 NS
 /// <reference path = "file1.ts" />
 /// <reference path = "file2.ts" />
 /// <reference path = "file3.ts" />
 f = new foo （ ） ;
 f 。 a （ ） ;
 f 。 b （ ） ;
 f 。 c （ ） ;

Module Augmentationは、ここでの問題の90％を解決します。 @svalloryの例を

/MyClass.partial.ts

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

MyClass.ts

// v- this would NOT throw an error because the definition is marked as partial
import { MyClass } from "./MyClass.partial";

export class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

モジュールの拡張は次のようになります...

MyClass.ts

export class MyClass {
    firstName = 'John';
    lastName = 'Smith';
}

MyClass.generated.ts

import { MyClass } from './test';

Object.defineProperty(MyClass.prototype, "fullName", {
    get(this:MyClass) {
        return this.firstName + ' ' + this.lastName;
    }
});

declare module './test' {
    interface MyClass {
        readonly fullName: string;
    }
}

部分クラスよりも少し冗長ですが、実際には、部分クラスはこの実装の構文糖衣構文にすぎません。

今日あなたが持っていない唯一の落とし穴は次のとおりです：

• this: MyClass構文を使用してプライベートフィールドまたは保護フィールドにアクセスすることはできません。
  
  
  
  • これは、 anyキャストすることで、生成されたコードで簡単に解決できます。
  
  
  • おそらくこれは、 this保護されたメンバーにアクセスできるように追加できるものです。 その周りに他のルールがあるかもしれません。
  
  
• 生成されたコードはもう少し威圧的に見えますが、消費者にとっては、一度拡張されると、違いを知ることはできません。

編集：これはTS2.0以降の構文であることに注意してください。

@ david-driscoll同意します。 それはもっと簡単だと思いますし、追加の構文が導入されていないのが好きです。 ご存知のように、私は特定の言語機能として部分クラスに反対していますが、TypeScriptがプロトタイプへの割り当てを一般的に追跡し、それに応じてオブジェクトの形状を改良すると有益だと思います。 あなたのアプローチは、クラスを複数のファイルに分割する正しい方法だと思います。

@wongchichongこの例では、グローバルクラス名と/// <reference path="..."/>ます。 名前空間を使用して状況を改善することはできますが、それがうまく拡張できるとは思いません。
モジュール（つまり外部モジュール）として記述されたコードは、順序に依存し暗黙的な依存関係を認識する必要があるローダーを含むため、非常に異なる獣です。 @svalloryの提案が価値があるのはそのためです。それは、依存関係を明示的にする非常に最小限の手動配線を必要とします。

誰かがモジュールを使用しない場合はどうなりますか？

@pankleksの部分クラスはまだ悪い考えです。

明確にするために、私はそれらがクラス宣言が宣言的ではなく命令的であるJavaScriptのような言語では悪い考えであることを意味します。 名前空間を使用している場合でも、コードを複数のファイルに分割することになります。つまり、これを機能させるには、それらのファイルのスクリプトタグの順序に依存する必要があります。

C＃のような言語では、部分クラスはうまく機能しますが、それはJavaScriptのクラスとは根本的に異なるためです。

JavaScriptでは、宣言はもちろん、クラス宣言も引き上げられないことを覚えておくことが重要です。

ES6を除いて、「クラス」の概念はTSによって定義されます。 JSには、クラスの概念はまったくありません。
では、クラスが何であるかを決定するのはTypeScript次第ですよね？

ES6を除いて、

TSの目標の1つは、現在/将来のES仕様に従うことであるため、TS言語機能について説明するときにES6を禁止することはできません。

確かに：/

コード生成クラス（エンティティ、サービスレイヤークライアントなど）を持つ大規模システムの場合、C＃設計による部分クラスは、生成されたコードを追加の状態と動作で拡張する必要がある場合に、非常に洗練されたソリューションを提供します。 私の現在のプロジェクトでは、約500のコード生成クラスがありますが、この機能がとても恋しいです。

「それは悪い考えだ」と言うことを除いて、他の場所で有用であることが証明されている機能に対して何人かの人々がなぜそれほど敵対的であるのか私はまだ理解していません。

これはesdiscussであまり議論されていないようです、私が見つけた唯一のスレッドには9つの投稿があります。

@ yahiko00私がその概念に敵対しているわけではありません。 あなたが言うように、それはC＃のような言語で非常に役に立ちます。

熱心なC＃プログラマーとして、部分クラスは特定のタスクに非常に役立つと思います。 ただし、それらは言語の他の側面に干渉しません。 これらは、名前空間、アセンブリ、任意に順序付け可能な型宣言などのキー関連の抽象化を壊しません。

一方、JavaScriptには、せいぜい初期のモジュールシステムがあります。 クラスは新しく、言語の表現力はまだあまり高くありませんが、成長するには時間が必要だと私は主張します。

少し前に戻って、C＃のもう1つの強力ではるかに便利な機能である拡張メソッドを検討すると、JavaScriptに追加されることを望んでいますが、そうすることには根本的な問題があり、まだ解決されていません。

モジュールなどのはるかに基本的な概念を壊したり、厳しく制約したりすることなく部分クラスを指定できるようになったとき、私はそれらを追加することに賛成します。

そうは言っても、 @ SaschaNazが指摘しているように、これはECMAScriptで対処する必要があります。

興味のある人は誰でもhttp://esdiscuss.orgで新しいスレッドを開いて、ここにURLを投稿して、そこで議論を続けることができます😄

PS：またはそれ以上-GitHubのようなES談話。
PS2：または、GitHubのようなよりアクティブなWICGでも。

私もTSのコード生成を可能にするいくつかの構造を見たいと思っています。 部分クラスは、C＃でこれに最適です。

何かが足りないかもしれませんが、コアの問題は、コンストラクター以外の場所、できれば別のファイルから「プライベート」変数にアクセスできるクラスを拡張することであるように思われます。

議論に基づくと、「安全な」TSイノベーションの多くが行われたようです。 今後は何も壊したくないので、ESガバナンス機関が何をするのかを待っています。 完全に有効ですが、TSでより速く動く列車を望んでいたので、少しがっかりしました。

前提条件は、適切な脱糖を見つけることです。

以前は、クラスに直接追加できるため、部分クラスはかなりばかげていると思っていましたが、そうすることで、メソッドを列挙できないようにし、スーパーバインディングを修正する必要があることを考えると魅力がわかります（後者は現在、 ES6）。

最初に、古いtoMethodのように、クラス一般を構成的で命令型のプリミティブに適切に保証することを理解する必要があります。 しかし、それができたら、人間工学的---またはそうでない---それらのプリミティブが最終的にどのようになるかに応じて、部分クラスのように砂糖を上に追加するのが合理的かもしれません。

これが正確に何を意味するのかわかりませんが、おそらく次のようになります。

class A {
  foo() { return "foo" }
}
class B extends A {
}

partial(B, class {
  get foo() {
    return super.foo(); // should work
  }
});

（クロスはesdiscussに投稿され

純粋なJSで部分クラスを実装する非常に簡単な方法があるようです（ ES2017 getOwnPropertyDescriptorsを使用）。 ESの人々は、この小さなコードを削除するためだけにシンタックスシュガーは必要ないと考えるかもしれません。

function partial(base, extension) {
  extension.prototype.__proto__ = base.prototype.__proto__; // to enable 'super' reference
  const descriptors = Object.getOwnPropertyDescriptors(extension.prototype);
  delete descriptors.constructor; // must not override constructor
  Object.defineProperties(base.prototype, descriptors);
  
  return base;
}

もちろん、これをTSで使用するには、既存のクラスタイプを拡張するためにinterface複製が必要です。

@SaschaNaz getOwnPropertyDescriptorsを介してコンストラクターに追加されたプロパティは、IDEの「自動暗示」では非表示になると思います（実行時に追加されるため）。 Typescriptは「自動暗示」を備えたJavaScriptとして生まれたことを忘れないでください（人々はそれを「強烈なタイプ」と呼ぶこともありますが、実際に好きなのは「自動暗示」です）。

PSなぜ人々は部分的なクラスを必要とするのか-コード生成。 ただし、コード生成は、IDE（ソースファイルへの簡単な「ツール」調整、ファイルエクスプローラーでの階層結果、T4または同様の「共通コードジェネレーター」サポート）と言語（部分クラス、拡張メソッド）の両方でサポートする必要があります。 これを理解して初めて、開発者が実際に何を求めているのかを理解することが可能になります。 全体像が見えない場合は、もちろん「部分クラス」は「ナンセンス」のように見えます。

@aluanhaddad ：しかし、TypeScriptの主な機能は、JavaScriptに存在しない言語要素を提供することではありませんか？ クラスを2つの部分的なTypeScriptファイルに分割し、それらを1つのJavaScriptファイルにコンパイルするのはなぜ悪い考えですか？

コミュニティにツールを提供することに問題はありません。 そして、私はそれを悪用する開発者がいると100％確信しています。 しかし、それを使用する方法を正確に知っている開発者もいます。 しかし、どの言語のどの構成概念でも同じ状況になりませんか？

コード生成の目的で+1。 そして、 @ rpokrovskijに同意し

@greendimka ESモジュールから分岐し、ESモジュールを大幅に複雑にすることなく、これがどのように機能するかはわかりません。

@ xiexin36 TypeScriptは、私にはC＃よりもJavaScriptのように思えます。
JavaScriptとC＃の間には共通点がありますが、 class概念は世界的に異なります。

@ xiexin36のコード生成では、モジュール拡張を引き続き使用できます（このスレッドで前述したように）。 構文的には、部分クラスほど「簡単」ではありませんが、同じタスクを実行できます。

@aluanhaddadええと、それは非常に簡単に機能します。部分クラスはコードの構造を変更しません。 同じクラスの定義を複数のファイル（とにかく単一のJSにコンパイルされる）に書き込むことができます。

@aluanhaddad厳密に言えば：javascriptにはクラスの概念がありません（ES6クラスは単に

@ greendimkaES6クラスとTypeScriptクラスは同じものです。
TypeScriptは、JavaScriptのランタイムに構造を追加することを目的としていません。

ES6クラスは_非常に_光沢がありません。 これは、JavaScriptが強力な言語ではないという意味ではありません（そうです）。 TypeScriptは静的型付けを提供して、設計時にエラーをキャッチし、高品質のツールを提供し、コンポーネントインターフェイスの非常に正確で厳密な仕様を可能にし、一般に生産性を向上させます。

ES6クラスは_非常に_光沢がありませんが、TypeScriptが独自のクラスの概念を導入することは、その設計目標に直接違反することになります。

クラスを避けるだけで、問題は解決します。

まあ、それは非常に簡単に機能します：部分クラスはコードの構造を決して変更しません。 同じクラスの定義を複数のファイル（とにかく単一のJSにコンパイルされる）に書き込むことができます。

そして、人間に知られているほとんどすべてのツールを壊しますか？ いいえ、結構です。

@ david-driscollありがとうございます、試してみますが、Angular2.0も使用しています。
@Inputまたは@Output 、それは動作します、とにかく私はそれを試してみます。

@aluanhaddad 「クラス？javascriptにはクラスがありません」を繰り返すことにどのように

ちなみに、TypeScriptチームは部分関数も提供してくれます！ 今のところ「関数内の関数」があるので、C＃チームにも同じことを伝えてください。 :)

念のために言っておきますが、部分関数には非常に特殊な意味があり、説明していることは想像力の範囲によって部分関数ではないことに気づいていますか？
コード生成は便利ですが、私も使っています。

@aluanhaddad 。 「複数のファイルに1つのコンパイルユニット」という用語を理解していますか？ もちろん、Javascriptはコンパイル言語ではありませんが、a）実行前に関数を完全に解析する必要があり、これを「コンパイル」と名付けることができます。b）Typescriptはコンパイル言語です。

あなたの想像力を助けるために：

function partial func(arguments) {
  return function() {
    return codegenerated(arguments);
  };
}

function partial func(arguments) {
   function codegenerated(arguments){
      // ...
   }
}

また、部分クラスはあまり使用しません。それらを効果的に使用するには、コード生成パラメーターを「手動」部分に格納する必要があり、この構成を読み取るには、適切な言語パーサー（リフレクションではない）が必要です。 しかし、その方法は次のとおりです。部分クラスは、コード生成を快適にするための多くの手段の1つにすぎません。

@rpokrovskij
敵対的であるとして外れた場合はお詫び申し上げます。 私は攻撃や軽蔑を意味しませんでした。

あなたの例には、それ自体でかなり正式な説明を必要とする側面があります。 この提案は元々、コード生成シナリオを直接有効にすることに関するものではありませんでした。

@aluanhaddad...。
「クラスを避けるだけで問題は解決します」-真剣に、それは問題の解決策ですか？！ おそらくJavaScriptの使用を避ければ、この議論全体の問題を解決できます。 解決策でもありませんか？ 残念ながら、私たちの宇宙にはこのくだらない言語があります。何年も前にWebにアクセスできたのは幸運だったからです。 とにかく、これはオフトピックです。

「人間に知られているほとんどすべてのツールを壊す」-それはどのように可能ですか？ どのように？！？！ TypeScriptで部分クラスを使用して何かを壊すことを想像しようとしていますが、できません。 私は単にできません。 ここで実際の例を教えてください。

今、あなたが箱を輸送するために車を作ったと想像してください。 問題なく動作します。 あなたは車を積み込む労働者を雇います。 作業員は一度に2つの箱を取り、車に入れます。 それでもすべてが正常に機能します。
ある日、労働者は別の会社に向けて出発し、あなたは新しい会社を雇います。 新しいものは、単一のボックスを取り、それをロードし、別の単一のボックスを取り、それもロードします。 論理的に：すべてが大丈夫です。 しかし、あなたは走り回って悲鳴を上げます：停止、停止、システム障害が発生しました！ :)

「クラスを避けるだけで問題は解決します」-真剣に、それは問題の解決策ですか？！ おそらくJavaScriptの使用を避ければ、この議論全体の問題を解決できます。 解決策でもありませんか？ 残念ながら、私たちの宇宙にはこのくだらない言語があります。何年も前にWebにアクセスできたのは幸運だったからです。 とにかく、これはオフトピックです。

ES2015には確かに多くの問題があります。 ES5.1には確かに多くの問題がありました。 私の意見では、クラスの欠如はそれらのことの1つではありませんでした。 私のポイントは、モジュールパターンを明らかにするなどの手法を使用することで、部分的なクラスが不要になるということです。 TypeScriptは、明らかにするモジュールパターン、名前空間に砂糖を提供します。

「人間に知られているほとんどすべてのツールを壊す」-それはどのように可能ですか？ どのように？！？！ TypeScriptで部分クラスを使用して何かを壊すことを想像しようとしていますが、できません。 私は単にできません。 ここで実際の例を教えてください。

ESモジュールを使用する場合、これは問題があります。 コンパイルされていない対応するものと対応するコンパイラの物理的なアーティファクトに依存するツールは、これの対象となります。 そうは言っても、TypeScriptは、大幅な変更である、emitでこれを調整できますが、作成したTypeScriptと一致しないJavaScriptを出力することになります。

したがって、基本的に、言語の進化はツールによって抑制されています。ツールは、言語の進化なしには決して進化しません。
申し訳ありませんが、ここでは進化しない理由の検索のみを表示します。

部分的なクラスがもたらす利点は何ですか？それは、言語を別の方法ですでに行うことはできませんか？ 確かに、それは素晴らしい構文糖衣ですが、本当の利益は何ですか？ C＃のようにする以外に具体的な例はありますか？

余談ですが、私がC＃開発者として始めた記録として、そこからJavaScript / C＃に移行しました。 TypeScript 0.8が発表されると、JavaScript用のC＃であるためではなく、厳密なJavaScriptを採用し、強力なタイプのC＃を楽しむ開発者にとってより良いものになっているために販売されました。

TypeScriptはC＃ではないため、C＃に機能があるという理由だけで、C＃から機能を厳密に継承するべきではありません。 C＃がTypeScriptから機能を継承してはならないのと同じように。 TypeScriptには非常に優れているため、C＃の共用体型などの機能が必要だった回数は数えられませんが、言語にはまだ適していません。

これまで、コード生成とコード編成を読みました。

コード生成、モジュール拡張を見てください。ここで指摘したいくつかの欠陥があり

コード編成、リージョンを使うと思います（笑）？ コードを整理する方法は他にもたくさんあります。（何らかの理由で）1つの神のクラスがある場合は、いつでもそれを多くの神のクラスに分割できます。 表面的には、神のクラスは誰もが見て使用するインポートですが、内部では、おそらく神のクラスのプロパティとして多くのクラスで構成されています。 組織化に部分クラスを使用している場合は、コードを少しリファクタリングして、コードをSOLIDする必要があると思います。

これまでに遭遇したほとんどのコード生成シナリオに拡張を適合させることができました。

Omnisharp-Clientの場合、ここではインターフェイス拡張機能を使用します。OmniSharp.Api.V2はC＃でのリフレクションを介して生成されます。 ファイルの下部には、そのインターフェイスのすべてのメソッドをスタブ化するツールがあります。

RxJSの場合、 Observableにあるすべてのメソッドを

部分クラスの問題のいくつかについては、私には理由がありません。 たとえば、3つの部分クラスが与えられたとします。

• MyAwesomeClass1.ts
• MyAwesomeClass2.ts
• MyAwesomeClass3.ts

スコープ：グローバルモジュール（ namespace / module ）

グローバルコンパイルは、これが最も簡単であると思われる場所です。 TypeScriptはすでに名前空間をマージしているため。

tsconfig.jsonにClass1とClass2のファイルパスのみが含まれている場合、Class3にあるものは自動的にマージされません。

• 最初はこれはユーザーエラーのように見えますが、Class3のメソッドが含まれていない理由はすぐにはわかりません。 これは、混乱を招く大きなユーザビリティの問題です。

範囲：外部モジュール（インポート/エクスポート）

外部コンパイルでは、各モジュールにはすべての依存関係（インポート）とすべてのパブリックAPI（エクスポート）の明示的なリストがあるため、各ファイルは実際にはモジュール（または.NETの世界では地獄のアセンブリ）と見なされます。

これらのシナリオについてどのように推論しますか？

ファイル参照が1つしかない場合、クラスの動作はどうなりますか？
Class2とClass3を自動的にマージしますか？

• Class1、Class2、Class3のデフォルトの定義はすべて、まったく同じ値をエクスポートしますか？
• どのファイルがディスクに出力されますか？
• サポートされているすべての形式（amd、umd、commonjsなど）で基盤となるJavaScriptはどのようになりますか

// somefile.ts
import { MyAwesomeClass } from 'MyAwesomeClass1';

new mac = new MyAwesomeClass();
mac. // What methods are available here?

クラスのすべてのインスタンスを明示的にインポートする必要がありますか？ （そうすると、目的のimoが無効になります）。
すべてを1つのファイルにインポートし、別のファイルにはインポートしないと、メソッドに何が発生しますか？
これは、余分なパーシャルなしでクラスが1回使用される複雑な依存関係グラフを考えると、本当に奇妙なエラーにつながる可能性があります。 値は増加しますか？ または、メソッドを取り込む他のファイルがロードされるまで、メソッドは魔法のように機能しませんか？

// somefile.ts
import { MyAwesomeClass } from 'MyAwesomeClass1';
import { MyAwesomeClass } from 'MyAwesomeClass2'; // or maybe import 'MyAwesomeClass2';
import { MyAwesomeClass } from 'MyAwesomeClass3'; // or maybe import 'MyAwesomeClass3';

new mac = new MyAwesomeClass();
mac. // What methods are available here?

@ david-driscollここに私の2セントだけ：

確かに、それは素晴らしい構文糖衣ですが、本当の利益は何ですか？

優れたシンタックスシュガーは、どの言語の要点でもありませんか？ 運用の観点から、必要なのはループ、if句、およびすべてを実行するための反復だけです。 残りは、生産性を高め、他の同様の非機能的品質を提供するために、_素敵なシンタックスシュガー_です。

そして、言語は一般的にコンピュータに指示する操作の部分に優れていますが、コードを書くことの組織的な部分を一般的に吸い込みます。 オブジェクト、クラス、継承などの文化的なアドホックアーティファクトがありますが、組織化操作のドメインと、ソースコードで順番に構築および表現しようとしているすべての抽象化を実際に説明する、確固とした理論的基盤、afaikはありません。良い方法でそれを扱うことができるように。

TypeScriptについて私が気に入っている点は2つあります。1。型付きのJavaScriptを使用できるため、クライアントで複雑なシステムを突然管理できるようになります。 2.型システムは非常に表現力があります（型システムの制限なしに人々が書くことができるすべての種類のパターンをJavaScriptで表現できるようにすることが強制されたため）。

しかし、コードの構造化に関しては、他のどの言語よりもそれほど厄介ではないと思います。 そして、私たちはここでもっと革新的になることができたらいいのにと思います。 ユーザーが言語の組織的な部分を自由に試すことができるようにします。 制限的で疑わしいのではなく、新しい構造的表現力を開き、それを目指して努力します。

部分クラスは、特にコード生成に非常に便利であるだけでなく、一般的な編成の自由度を高めます。 このコード編成のタールピットから抜け出すために必要な自由。

@ david-driscollパーシャルを持つことのポイントは何ですか？ さて、もう一度：コード生成。
提案されたソリューションの何が問題になっていますか？ これは回避策です。 さらに別の回避策（そしてかなり汚い回避策）。 私たちはすでに、回避策でいっぱいのくだらない言語（javascrtipt）を持っています。 javascriptの開発者は、主なタスクについて考える代わりに、回避策について考えることに多くの時間を費やしています。 あなたの提案した哲学で、私たちはTypeScript言語全体を捨てることができます。 （サプライズ、サプライズ）型システム全体を、回避策を使用して純粋なJavaScriptでシミュレートできるためです。 回避策を使用して何かをシミュレートできるのに、なぜより表現力のある言語（Typescriptなど）を気にするのですか？ 同じことが20行で書かれているのに、なぜ1行のコードを書くのでしょうか。 書かれたコードの数行に基づいて給与を取り戻します！ 短くて表現力豊かなコードは猫用ですよね？

いいえ：TypeScriptにパーシャルを含める要求は、C＃にパーシャルがあるという考えに基づいていません。 TypeScriptには、他の言語にあるので、それを持っているという理由だけで何かがあるべきだとは思いません。

そして最後に：なぜあなたは何かを使わなければ-誰もそれを必要としないと思いますか？

@greendimka私は敵意をシールド：。 私は単にシナリオを理解しようとしているだけです。あるいは、率直に言って完全に可能であることに気付いていないシナリオがある場合は！

私はTypeScriptチームに所属しておらず、単なる支持者ですが、チームはここではかなり沈黙していることを覚えておいてください。 チームは、彼らが何か特別なことを言うことがあるとき、非常にうまくチャイムを鳴らすかもしれません、そして彼らがそうすることを選ぶならば、私は彼らに任せます。

TypeScriptチームが保持している主要なテナントの1つは、TypeScriptをECMAScriptの方向と同期させ、JavaScriptが進化している全体的な方向から逸脱する可能性のある特定の機能を作成しないようにすることです。

私がそれを使わないというわけではありません（おそらくそれが存在した場合）。 問題は、この問題の現状では、部分クラスには警告がある可能性があるため、すぐに実装されるかどうかは疑わしいようです。 a）価値の高い利害関係者にとって必須の機能になるか、b）提案がTC39の後の段階に進むまで、おそらくしばらくはこのままです。

ModuleAugmentationを回避策とは考えていません。 これにより、型システムを拡張でき、このスレッドで詳しく説明されているコード生成シナリオの多くが可能になります。 これは、他の言語機能への一歩です。

• 醜いですか？ 絶対に、すべての地獄のように醜い。 つまり、コードを生成している場合、違いは何ですか？ クラスを拡張する方法について心配する必要があるのは、生成ツールだけです。 コード生成ツールを実行し、モジュールを含めると、完全なインテリセンスやコンパイルエラーなどが発生します。

• 完璧ですか？ それからは程遠い！ ミックスインを言語レベルでサポートする必要がある、はるかに一般的なシナリオがあります。 また、具体的な提案はありませんが、ここで提案されていると思います。

@ david-driscoll、非常に失礼でごめんなさい。 私は本当に前向きな進歩の側に立つ傾向があります。

静的実装を部分クラスに配置できるように、これが必要です。

これがすぐに実現するようには見えないので、私たちが見つけた回避策を提案したいと思います。 このようなコメントがいくつかありますが、私はこれらの詳細を読んでいるものを見ませんでした。

生成されたTypeScriptコードを拡張できるようにするコード生成シナリオで使用するPartialsが必要です。 ただし、相互依存性のあるモデルを生成しているため、クラスからの継承は従来の意味ではうまく機能しません。 他のクラスを参照する生成されたクラスは、参照されるオブジェクトの正しいタイプではなく、正しいインスタンスタイプを作成するための複雑なファクトリパターンになります。

生成されたクラスを基本クラスに変更することになりましたが、クラス宣言のみでした。 次に、新しい基本クラスから継承するスタブクラスを作成しました。 次に、これらの新しいクラスを拡張すると、基本クラスからすべてのコンテンツを継承します。

例えば：
クラスPersonを生成した場合、PersonBaseを生成します。 生成されたすべてのコードはこのクラスに入ります。 また、PersonBaseを拡張する空のクラスPersonを生成します。 このクラスは一度だけ生成されます。 次に、生成されたすべてのコードをPersonBaseに配置し、すべてのカスタムコードを手動でPersonに配置します。 生成されたPersonへの参照はすべて、PersonBaseではなくPersonとして残ります。 このようにして、すべてのIntelliSenseが引き続き機能します。

ファイル1：基本クラス

module ViewModels {
    export class PersonBase {
        // Generated members
        public anotherPerson: Person;
        constructor(){
            // Generated constructor code
        }
    }
}

ファイル2：実際のクラス

module ViewModels {
    export class Person extends PersonBase {
        // Custom methods
        public NewVariable: string = "NewVar";
        constructor() {
            super();
            // Custom constructor code
        }
    }
}

これにより、生成されたコードに関する部分的なクラスの問題が解決されました。 アイデアを思いついたアンドリュー・スコットに称賛を送ります。

コードジェネレーターを使用してコードを生成しているので、これも本当に必要です。それにいくつかの変更を加える必要があります。 部分クラスを使用すると、後で変更を再度追加しなくてもコードを再生成できます（大きくても複雑な場合もあります）。

まだ言及されていないと思う部分的なクラスがあるという重要な理由があります。それは、JSをTSに徐々に移行することです。 Javascript、特にES6より前のクラスでは、クラスは次のようになります。

Foo.prototype.someFunction = function() {/*....*/}

また、これらは特別な処理なしで複数のファイルに分散できます。 このようなコードベースを最新のTypeScriptに変換するには、現在、クラスのすべてのメンバーが同じファイルに含まれるように関数を移動する必要があります。これは、かなり侵襲的な変更になる可能性があります。 部分クラスでは、ローカル編集のみを使用して移行を実行できます。

@RyanCavanaughここで要求されるものはすべて、他のTypeScript構文で構文的に処理できると

ミックスインの提案にはもっと多くの未解決の質問があると思います。 ここでの部分的なクラス提案は、TypeScriptですでに許可されているものを体系化したものであり、構文糖衣構文が含まれています（この機能は、文字通り、既存のものへの構文の再マッピングとして実行できます）。

では、TypeScriptでこれを行うにはどうすればよいでしょうか？：
File1.ts：

// Imagine this file is code generated and could be regenerated during development
export partial class Contact
{
    firstName: string;
    lastName: string;
    partial OnInit( args: any ) : void;
    constuctor( args: any )
    {
        this.OnInit( args );
    }
}
export class Address
{
    addr: string;
    city: string;
    state: string;
    zip: string;
}

File2.ts

// See where I'm going with this? This file would be hand edited and allows me to specify associations and children.
partial class Contact
{
    Addresses: string[] = [];
    partial OnInit( args: any ) void
    {
        this.firstName = args.firstName;
        this.lastName = args.lastName;
        this.Addresses.push( new Address() );
    }
}

上記をトランスパイルすると、Contact用に1つのJSクラスが出力されます。

var Contact = (function () {
    function Contact() {
         this.Addresses = [];
   }
   Contact.prototype.constuctor = function (args) {
       this.OnInit( args );
   };
   Contact.prototype.OnInit = function (args) {
       this.firstName = args.firstName;
       this.lastName = args.lastName;
       this.Addresses.push(new Address());
   };
   return Contact;
})();

var Address = (function () {
    function Address() {
    }
    return Address;
})();

最後に、Contactという名前の1つのクラスが必要であり、2つの別々のクラスを3番目のクラスにサブクラス化する必要がないことに注意してください。

@cosmoKenney

これが機能するものの例です。 partialほど構文的には問題ありませんが、機能し、非常に機能的なソリューションです。

// address.ts
export class Address
{
    addr: string;
    city: string;
    state: string;
    zip: string;
}

// contact.impl.ts
import { Address } from './address';

// Class implementation, do the things here that are not code generated
export class Contact {
    firstName: string;
    lastName: string;
    addresses: Address[];
    constructor(args: any) {
        this.onInit(args);
    }
}
// extending the interface here
// define methods you know will need in the constructor only
// This only applies to the constructor however
export interface Contact {
    onInit(args: any): void;
}

// contact.partial.ts
import { Contact } from './contact.impl';

// Implement the extended contract here
Contact.prototype.onInit = function(this: Contact, args: any) {
    this.addresses = args.addresses.concat();
    // do stuff;
};

// Adding another method (not part of the extended interface)
Contact.prototype.somethingAwesome = function(this: Contact) {
    // do awesome stuff here
};

// Tell TypeScript "I added this here!!!!"
declare module './contact.impl' {
    interface Contact {
        somethingAwesome();
    }
}

// contact.ts
import { Contact } from './contact.impl';
import './contact.partial';

// Bring it all together (perhaps there are more than one partial class?)
export { Contact };

// main.ts
import { Contact } from './contact';

// use the contact!
const contact = new Contact(['my', 'args']);
const {firstName, lastName} = contact;
contact.somethingAwesome();

あるいは、インターフェースをコード生成し、それを実装するインターフェース拡張機能を使用することもできます。

新しいMixin機能を使用する方法もあるかもしれませんが、私はまだそれについて深く掘り下げていないので、適切な答えを出すことができません。

@ david-driscollうわー。 頭が爆発した。

コミュニティは、問題を吹き飛ばすことなく部分的なクラスをサポートするだけのフォークで終わるのではないかと思います。
これまでのところ、部分的なクラスに対する実際の議論は聞いたことがありません。 怠惰を正当化する理由はほんのわずかです。

@greendimka

コミュニティは、問題を吹き飛ばすことなく部分的なクラスをサポートするだけのフォークで終わるのではないかと思います。
これまでのところ、部分的なクラスに対する実際の議論は聞いたことがありません。 怠惰を正当化する理由はほんのわずかです。

ここで何を言おうとしているのかわからない。 しかし、コミュニティ内の全体的な感覚が、既存の言語機能を使用して同じ結果を達成できるということである場合、それを行う方法のいくつかの例が必要です。 @ david-driscollが上に投稿したものは、私の理解をはるかに超えています。 そして、問題を完全に解決していないようです。 実際、私が言えることから、彼は私の意図を誤解していた。
私の主な関心事は、pojoやモデルクラスのようなクラスのスカラープロパティをコード生成することです。 ただし、別のファイルまたは同じファイルで、プライマリクラス定義内に関連付けプロパティを追加できないようにする必要があります（これにより、新しくコードで生成されたプライマリ定義を元の定義に貼り付けることができます）。
たとえば、上記のContactクラスは、firstNameとlastNameで生成されたコードを取得します。 しかし、私の別の定義では、Addressオブジェクトのコレクションの定義と初期化を追加します。
私のコードジェネレーターは、関連付けではなくクラスの属性のみを認識しているため、davidの例で行われたように、アドレスコレクションをコード生成することはできません。

@cosmoKenneyアドレスがどこにあるべきかは完全には明確ではありませんでした。 文脈を間違えることを許してください。 私はただ選択肢を与えるのを手伝おうとしています。 部分クラスのようにコンパイラに何かを入れずに同様の動作を可能にする機能はたくさんあります。これらには、両方のモジュールシステム（内部/外部）を実装するための多くの追加の考慮事項と潜在的な問題があります。

あなたの場合、抽象基本クラスを生成するか、インターフェース生成が機能する場合、他のクラスはそれを継承します。 その後、クラスが生成されたという事実はまだ隠されています。

NS：

// address.partial.ts
export interface IAddress
{
    addr: string;
    city: string;
    state: string;
    zip: string;
}

// address.ts
import { IAddress } from './address.partial';

export class Address
{
    constructor(args: any) {

    }
}
export interface Address extends IAddress{}

// contact.partial.ts
import { IAddress } from './address.partial';

export interface IContact {
    firstName: string;
    lastName: string;
    addresses: IAddress[];
}

// contact.ts
import { Address } from './address';
import { IContact } from './contact.partial';

// Class implementation, do the things here that are not code generated
export class Contact {
    addresses: Address[] = [];

    constructor(args: any) {
        this.firstName = args.firstName;
        this.lastName = args.lastName;
        this.addresses.push( new Address("address?") );
    }

    public somethingAwesome() {
        //
    }
}
export interface Contact extends IContact {}

// main.ts
import { Contact } from './contact';

const contact = new Contact(['my', 'args']);
const {firstName, lastName} = contact;
contact.somethingAwesome();

@cosmoKenney ：@ david-driscollは興味深いソリューションを提供しますが、それでも実際の部分クラスの使いやすさに欠けています。 私の個人的な実験が示しているように、開発者はこの方法で作成された「部分」を使用しません。 これは優れた回避策ですが、パーシャルの使いやすさと快適さはありません。

現時点では、TypeScriptコンパイラが内部でどのように機能するかわかりません。 私はそれがすべてのソースファイルを読み取り、それらを進め、JSファイルを出力すると仮定することしかできません。 もしそうなら-私はいくつかのソースファイルから単一のクラスを読み取ることに問題は見られません。 1つのクラスの2つ以上のソースファイルが競合するコードを提供する場合（同じプロパティが2回定義されている場合）、コンパイラは単に例外をスローします。 構文的に無効なコードを記述した場合と同じように。

@ greendimka 、@ david-driscoll
私はDavidの例を上からコンパイルしようとしましたが、tsはそれが好きではありません：

C:\TestProjects\TypeScriptFakePartialClassTest>tsc -m amd address.partial.ts address.ts contact.partial.ts contact.ts main.ts
address.ts(4,14): error TS2300: Duplicate identifier 'Address'.
address.ts(10,18): error TS2300: Duplicate identifier 'Address'.
contact.ts(7,14): error TS2300: Duplicate identifier 'Contact'.
contact.ts(11,14): error TS2339: Property 'firstName' does not exist on type 'Contact'.
contact.ts(12,14): error TS2339: Property 'lastName' does not exist on type 'Contact'.
contact.ts(20,18): error TS2300: Duplicate identifier 'Contact'.
main.ts(5,8): error TS2459: Type 'Contact' has no property 'firstName' and no string index signature.
main.ts(5,19): error TS2459: Type 'Contact' has no property 'lastName' and no string index signature.

さらに、 @ greendimkaは、これが複雑すぎて大規模なアプリケーションで何百回も使用できないことに同意します。

@greendimkaコンパイラがどのように機能するかはわかりませんが、タスクを過小評価しないでください。 JavaScriptは.NETではなく、モジュールはグローバルに利用できません（文字通りインポートする必要があります）

これが実装されるのを見たいのですが、このタスクでは、次のように慎重に検討する必要のあるいくつかのことが発生します。

• クラスの一部をファイルAに定義し、一部をファイルBに定義する場合、変換後にクラス全体を含める必要があるのはどれですか？ 新しいものを生成する必要がありますか？
• 部分的なものを含むすべてのファイルが同じクラスをエクスポートする必要がありますか？
• それらの追加のメインファイルが必要な場合、循環依存を回避するにはどうすればよいですか？
• クラス自体よりも多くのものをモジュールにエクスポートするとどうなりますか？
• 名前の競合チェック？

等々...

@greendimka以下の私の回答を参照してください:(編集：これは@WoLfulusを対象としてい

クラスの一部をファイルAに定義し、一部をファイルBに定義する場合、変換後にクラス全体を含める必要があるのはどれですか？ 新しいものを生成する必要がありますか？

ファイルA.jsに完全な定義があり、ファイルBがスタブオフされていれば完全に嬉しいです。 たぶん、缶詰のコメントで。 とにかく私たちのほとんどはバンドルしているので、バンドルされる無数の.jsファイルは、最終的には本質的に後から考えたものになります。

部分的なものを含むすべてのファイルが同じクラスをエクスポートする必要がありますか？

これは、最初の質問に対する私の回答によってほぼ答えられます。

それらの追加のメインファイルが必要な場合、循環依存を回避するにはどうすればよいですか？

わからない。 このシナリオを認識するのはモジュールローダーの仕事ではありませんか？

クラス自体よりも多くのものをモジュールにエクスポートするとどうなりますか？

これには問題はありません。 言い換えると、B.tsに部分的な定義と他のいくつかの非部分的なクラスの両方がある場合、B.jsには、上記の定型コメントと非部分的なクラスの定義を含める必要があります。 シンプルだと思います。

名前の競合チェック？

どのようにして名前の競合が発生しますか？ クラスを意味する場合、「partial」キーワードはそれを解決します。 しかし、他の2つのファイルが両方とも同じ名前でクラスを定義しているが、「partial」キーワードがない場合、コンパイラーは重複タイプについてエラーを出力するはずです-現在のように。 しかし、同じ名前のプロパティまたはメソッドを定義する同じクラスの2つの部分的な定義について話している場合、コンパイラは、現在のように、重複するメンバーについてエラーを出力する必要があります。

@ WoLfulus 、 @ cosmoKenneyはよく答えました。 最初の質問（AファイルとBファイルについて）でそれを改善するために：言語設計者として、ルールを定義する特権があります。 つまり、ファイルAにはそのようなコード「partialclass X」があり、ファイルBにはそのようなコード「partial（fileX）class X」があり、fileX.jsが生成されます。

@cosmoKenney

それらの追加のメインファイルが必要な場合、循環依存を回避するにはどうすればよいですか？
わからない。 このシナリオを認識するのはモジュールローダーの仕事ではありませんか？

TypeScriptにはモジュールローダーがありません。

@greendimka

コミュニティは、問題を吹き飛ばすことなく部分的なクラスをサポートするだけのフォークで終わるのではないかと思います。
これまでのところ、部分的なクラスに対する実際の議論は聞いたことがありません。 怠惰を正当化する理由はほんのわずかです。

それは良い考えではありません。 たとえば、動的インポートが追加されたときにフォークをどのように維持するかを検討しましたか？
また、部分的なクラスに対して多くの議論がなされてきました。 TypeScriptファイルとJavaScriptファイルの間のソース間の対応を破ることは、言語の重要な信条に反します。 機能が考慮されるためには、部分クラスよりも無限に価値のあるシナリオを可能にする必要があると思います。 それでも拒否される可能性があります。

@ WoLfulus 、 @ cosmoKenneyはよく答えました。 最初の質問（AファイルとBファイルについて）でそれを改善するために：言語設計者として、ルールを定義する特権があります。 つまり、ファイルAにはそのようなコード「partialclass X」があり、ファイルBにはそのようなコード「partial（fileX）class X」があり、fileX.jsが生成されます。

私はあなたがあなたのメッセージを伝えているとは思わない。 それは、あなたがどんな言語ででも自分自身を表現することに遭遇するどんな制限も完全に恣意的な理由で存在するように感じるように聞こえます。
また、 @ WoLfulusの質問には、少なくとも私の満足には答えられませんでした。

フレームスーツを着用

TL; DR：これは起こっていません。 コメント番号189でここにいて、不承認を登録したい場合は、最初にスレッド全体を読んでください。これを追加しない理由は上記で詳しく説明されています。

この状況の解釈は次のとおりです。

• TypeScriptには、TS固有のクラス機能（コンストラクタープロパティ宣言、メンバー初期化子、非ファイナライズされたデコレーター、アクセス修飾子、 implementsなど）がすでに多すぎて、実際には「ES6 +型」であることが意図されていました。 。 その一部は私たちのせいであり（私たちの元の設計の方向性は一般的にOOPでした）、その一部はES6のせいです（クラスの提案は5年前にかなり動き回り
• 明らかに、JavaScriptの未来はモジュールです。 部分クラスは、「グローバルスープ」モデルでのみ意味があり、適切に機能します。 複数のモジュールにまたがる部分的なクラスを許可することは、ロードの順序が予測できないため、災害のレシピです。 グローバルのみのユニバースでのみうまく機能する機能を追加することは、時間の有効活用ではありません。
• C＃にはそれがありますが、C＃を再発明するためにここにいるわけではありません。 真剣に！
• 「生成されたコード」シナリオは、メリットに説得力がありません。 部分クラスのもっともらしいemitは、プロパティ初期化子とコンストラクターコードを1つの宣言に制限します。これは、ユーザーコードと生成されたコードの両方に初期化子またはコンストラクターロジックが必要になる可能性があるため、 .Designer.csスタイルのセットアップの大失敗になります。 。
• JSには、ミックスイン、 Object.assignなど、他にも多くの構成メカニズムがあります。C＃でこの機能を実現するシナリオは、JSには存在しない制約によって引き起こされました。
• 現在の回避策interface + prototype.method = ...ちょうどだけでなく、生成されたコードのシナリオを有効にするんpartial classでしょう。 そのコードを手で書くのは奇妙ですが、コードを別の方法で生成するのに問題はありません。したがって、分割ファイルで生成されたコードセットアップが問題を解決する唯一の方法であると本当に思う場合（私は懐疑的です）、その方法を利用できます。
• ES6は、クラスの「必須」のアービターであると考えています。 TypeScriptには、型なしのJavaScriptよりも部分的なクラスが必要になるという特別なことは何もありません（C＃プログラマーにとって魅力的です）。 したがって、部分的なクラスを追加するために実際に公園からそれをノックアウトするシナリオがある場合、そのシナリオはTC39プロセスを通じてそれ自体を正当化できるはずです。 それが牽引力を獲得した場合、私たちはそれに入力を入れて喜んで検討しますが、これは誰のレーダーにも載っていないようです。

これについて

インターフェイス+ prototype.method = ...の現在の回避策は、部分クラスと同じように、生成されたコードのシナリオを有効にします。

何度も言及したように、必要なことを達成するための非部分的、非C＃の方法があるので問題ありません。そして、実際の例を求めてください。 david-driscollは非常に役に立ちましたが、コンパイルされないコードを投稿しました。 したがって、たとえば、上記のように、姓、名のみのスカラープロパティを使用してクラスをコード生成できると思われる場合は、それで問題ありません。 他のタイプのコレクションをクラスのプロパティとして手動でコーディングする方法が必要です。 しかし、そのセットの初期化を処理する方法も必要です。

@cosmoKenneyあなたは正しいコードをコピーしたサイトですか？ 2番目の例では、同じクラス名の代わりにインターフェイスがありました。 必要に応じて、コードのzipを添付できます。 インターネット上のランダムなファイルが悪い可能性があり、私が悪意のあるものを投稿しているとあなたに思わせたくなかったので、私はただ躊躇しました🙂

これを聞いて申し訳ありませんが、私はここで行われた設計上の決定を尊重します。 それでよろしければ、いくつか質問があります。

TypeScriptには、実際には「ES6 +タイプ」を意図したものに対して、TS固有のクラス機能（コンストラクタープロパティ宣言、メンバー初期化子、非ファイナライズされたデコレーター、アクセス修飾子、実装など）がすでに多すぎます。 その一部は私たちのせいであり（私たちの元の設計の方向性は一般的にOOPでした）、その一部はES6のせいです（クラスの提案は5年前にかなり動き回り、機能がうまくいかなかった）。 さらに別のTS固有のクラス機能を追加することは、ラクダの背中にあるもう1つのストローであり、可能であれば避ける必要があります。

これを考慮すると、JSの純粋なタイピングと、TSが提供する他の言語構造とを、組織的およびコード的に明確に区別することが可能でしょうか。 私は、タイピングと追加の言語機能の両方が大好きです。 消費者/開発者として、私はTSがJSにないものを追加するという事実についてはあまり気にしません。 素晴らしいものをください。TC39がそれを望まないのなら、私は気にしません。

TSがこれらのものを相互にカプセル化する場合、置き換えられるのではなく、再利用が容易になり、SoundScriptなどのプロジェクトによってフォークおよび構築される可能性がありますか？

そして、他のプロジェクトがこのタイピングに基づいて構築され、JSが提供するよりも優れた/他の言語構造を提供することができます。

明らかに、JavaScriptの未来はモジュールです。 部分クラスは、「グローバルスープ」モデルでのみ意味があり、適切に機能します。 複数のモジュールにまたがる部分的なクラスを許可することは、ロードの順序が予測できないため、災害のレシピです。 グローバルのみのユニバースでのみうまく機能する機能を追加することは、時間の有効活用ではありません。

本当か？ モジュールがJavaScriptの自然な部分になることは確かですが、元のコード本体はどうでしょうか。 私はnamspacesが大好きで、適切に行われればスープはありません。 すべてを1つのファイルにコンパイルしているので、モジュールローダーは必要なく、ほとんどの場合、非同期モジュールロードも必要ありません。 https://github.com/Microsoft/TypeScript/issues/420のように提案されたものは、名前空間でのみ可能であり、関連性があります。 モジュールだけを使うべきなので、このようなことは起こらないと言っているのですか？ 名前空間は非推奨への道を進んでいますか？

@ david-driscollありがとうございます、あなたはすでに十分に助けてくれました。 @RyanCavanaughは問題を閉じ続け、

また、部分クラスとは何かについて多くの誤解が見られます。 これは本当に単純な構成であり、誰もがこれを不釣り合いに吹き飛ばしています。
https://msdn.microsoft.com/en-us/library/wa80x488.aspx

これを考慮すると、JSの純粋なタイピングと、TSが提供する他の言語構造とを、組織的およびコード的に明確に区別することが可能でしょうか。 私は、タイピングと追加の言語機能の両方が大好きです。 消費者/開発者として、私はTSがJSにないものを追加するという事実についてはあまり気にしません。 素晴らしいものをください。TC39がそれを望まないのなら、私は気にしません。

それは言語の書き直しであり、みんなのコードを壊します。

また、「Just give me awesome stuff」は、TypeScriptの設計目標とは根本的に異なります。 すばらしいものが必要で、JavaScriptとの整合性を気にしない場合は、 CoffeeScript 、 Dart 、 Haxeなどの別の言語を選択する必要があります。 もちろん、TypeScriptの採用ほどうまくいかない理由があるかもしれません...

問題を閉じ続け、回避策があると述べている人は、おそらく回避策の例を提供する必要があります

partial解決するものには多くのユースケースがあります。 ほとんどすべての言語構成には、それが有効な多くのユースケースがありますが、正当な理由から、選択する必要があります。

「私は緑の車が大好きです」のように、特定の言語機能を求め続けますが、問題の核心に到達していません。なぜ車は緑である必要があるのですか？ あなたがあなたの車がなぜ緑である必要があるかを説明したか、それがあなたの本当の必要性を提供する限り、あなたがあなたの車がどんな色であるかを実際に気にしないという事実にオープンであるならば。

正当な理由で自動車会社がグリーンカーを生産しないことを決定したという理由だけで、あなたがあなたの車を塗り直す方法をあなたに教えることがライアンの義務であるとあなたが感じる理由がわかりません。

（ああ、TypeScript 2.2で追加されたミックスインクラスは、あなたの本当のニーズであると私が思うことを達成するための良い方法です）

interface Base {}

interface Constructor<T> {
    new (...args: any[]): T;
    prototype: T;
}

interface PartialClass {
    foo(): void;
}

function PartialClass<B extends Constructor<Base>>(base: B): B & Constructor<PartialClass> {
    return class extends base {
        foo() {
            console.log('foo');
        }
    };
}

class MyBase {
    bar() {
        console.log('bar');
    }
}

const MyPartialBase = PartialClass(MyBase);

const instance = new MyPartialBase();

instance.bar();
instance.foo();

@kitsonkミックスインは同じものではありません。

• ミックスインは、既存のクラスに追加できる自己完結型のユニットです。
• パーシャルクラスは、同じクラスの一部であるかのように、他のパーシャルからメンバーにアクセスできます。

演習として、ミックスインを使用して次のコード分割を実装してみてください。

partial class Point {
  readonly x: number;
  readonly y: number;
}

partial class Point {
  translate(dx: number, dy: number): Point {
    return new Point(this.x + dx, this.y + dy);
  }
}

演習として、ミックスインを使用して次のコード分割を実装してみてください

さて、要点に戻りましょう...では、言語機能を指摘する代わりに、例でどのような問題に対処しようとしていますか？ TypeScriptでの回避策は簡単なので、次のようになります。

class Point {
  readonly x: number;
  readonly y: number;
  translate(dx: number, dy: number): Point {
    return new Point(this.x + dx, this.y + dy);
  }
}

（そして、私たちが完全主義者である場合でも、すべてのユースケースではなくします）

interface PointBase {
    x: number;
    y: number;
}

interface Constructor<T> {
    new (...args: any[]): T;
    prototype: T;
}

interface TranslatePointPartial {
    translate(dx: number, dy: number): TranslatePointPartial;
}

function TranslatePointPartial<B extends Constructor<PointBase>>(base: B): B & Constructor<TranslatePointPartial> {
    return class TranslatePointPartial extends base {
        translate(dx: number, dy: number): TranslatePointPartial & PointBase {
            return new TranslatePointPartial(this.x + dx, this.y + dy);
        }
    };
}

class Point {
    readonly x: number;
    readonly y: number;
}

const MyPoint = TranslatePointPartial(Point);

const instance = new MyPoint();

instance.x;
instance.y;
instance.translate(1, 2);

@ Elephant-Vessel

これを考慮すると、JSの純粋なタイピングと、TSが提供する他の言語構造とを、組織的およびコード的に明確に区別することが可能でしょうか。

現時点では、2つを解きほぐす方法がわかりません。 理論的には、構文的にTypeScriptに変換されたCoffeeScriptの言語を記述し、その高水準言語を使用して、TSの型システムを使用しながら、新しい構文機能を追加することもできますが、それではこれまでのところしか得られません。 それが目標である場合は、代わりに、他の多くのグリーンフィールドのコンパイルからJSへの言語の1つを選択する方が良い選択のように思われます。

モジュールだけを使うべきなので、このようなことは起こらないと言っているのですか？ 名前空間は非推奨への道を進んでいますか？

確かに、名前空間はどこにも行きません。 これらは、すでに広く使用されているパターンの単なる名前であり、ES6モジュールの世界ではまだ十分に意味があります。 モジュールはますます人々がコードを整理する方法であり、多くの大きな副次的な利点があります。 その世界では部分的なクラスはほとんど意味がないと言っているだけであり、それと互換性のない根本的に新しい組織パターンを追加するのは奇妙なことです。 世界が反対方向に動いていて、誰もが「負荷に副作用のあるグローバルスクリプトは素晴らしい、みんながお互いのprototypeパーティーをする」のようだったとしたら、私たちは違った気持ちになるかもしれません。

@RyanCavanaugh

おそらくそうです...おそらくあまり意味がありません...しかし、私が何度も言ったように、このスレッドでも、部分クラスはすべてコード生成を簡単にすることだと思います...それが私が見る主な利点ですそれらからTSの機能の価値があります...私と私は他の多くのことを想定する必要がありますが、それは単なる推測であり、現在私のC＃コードから大量のTSコードを生成しています...しかし、問題は生成されたものを安全に拡張する方法になりますTSコード??? これは部分的なクラスで答えるのがはるかに簡単な質問です...現在、生成されたTSコードファイルにカスタムコードを保持するためにハックに頼っています...

ありがとう

ここでも同じことですが、C＃APIのタイプスクリプト「プロキシ」を生成し、これらのオブジェクトをタイプスクリプトで簡単に拡張できるようにしたいと考えています。

私はJSスペシャリストではないので、何かが足りないに違いありません。なぜなら、クラスの宣言を複数のTSファイルに分割できる（コンパイル後に1つのJSファイルに1つのクラス宣言しかない）理由がわからないからです。 JSの世界にとっての問題。 私が見る限り、最初から1つのファイルに書き込まれているかのように、JSにとっては透過的です。 つまり、部分クラスを使用するかどうかに関係なく、JS出力はまったく同じになりますが、開発者にとってJSオブジェクトの拡張性のコストを防ぐことができます。

@RyanCavanaugh

私が個人的に言及したいもう1つのことは、異なるTSファイルで部分クラスを使用してES6モジュールを作成するときに発生する可能性のあるパッケージングのジレンマを何らかの方法で解決するようにTSコンパイラに依頼していないことです...少なくとも私には完全に理にかなっていますES6モジュール用に複数のTSファイルを単一のjsファイルにコンパイルします...繰り返しますが、部分クラスはコード生成を大幅に支援します...ツールが信頼できる拡張性でモデルの大部分を作成できるようにします...

@kitsonk

「私は緑の車が大好きです」のように、特定の言語機能を求め続けますが、問題の核心に到達していません。なぜ車は緑である必要があるのですか？ あなたがあなたの車がなぜ緑である必要があるかを説明したか、それがあなたの本当の必要性を提供する限り、あなたがあなたの車がどんな色であるかを実際に気にしないという事実にオープンであるならば。

いいえ、私はもう新機能を求めていません。 言語は私が望むことを達成できると何度も言われてきました。 必要なものの例を（C＃で）提供しましたが、役立つ例では、必要な場所に到達する方法をまだ確認していません。

正当な理由で自動車会社がグリーンカーを生産しないことを決定したという理由だけで、あなたがあなたの車を塗り直す方法をあなたに教えることがライアンの義務であるとあなたが感じる理由がわかりません。

ライアンはここでモデレーターのようで、問題を解決しています。 それが理由です。 彼が言語の権威である場合、母国語の機能を使用してそれを行う方法の例を提供せずに、私の必要性を理解し、この要求を却下する努力をする前に、おそらく彼は問題を閉じるべきではありません。 コンパイル時のソリューションが欲しいと述べました。 そして、私はかなり優秀な開発者であり、しばらくの間、多くの異なるあいまいな言語でプログラミングを行ってきましたが、ミックスイン構文にはまだ本当に苦労しています。 複雑で理解しにくいものがどのように言語に取り入れられたかはわかりませんが、C＃から借用しているため、部分的なクラス構文の優雅さを誰もが拒否しているようです。

ライアンはここでモデレーターのようで、問題を解決しています。 それが理由です。 彼が言語の権威であるなら、おそらく彼は私の必要性を理解する努力をする前に問題を閉じるべきではありません

🤔

@RyanCavanaugh 、あなたが助けようと努力したことを私は知っています。 そしてこの時点で、私はミックスインを試すことに移っています。 または単に継承、あるいは私はこのプロジェクトを成し遂げるためにとても急いでいるので、ジェネリックでこれを行う方法を見落としています。 うーん...
継承と命名により、私は次のことができます。

class AddressBase // this is a code generated class
{
    public address: string;
    public city: string;
    public state: string;
    public zip: string;

    constructor( jsonFromService: any )
    {
        this.OnInit( jsonFromService );
    }

    OnInit( jsonFromService: any )
    {
        // could use Object.assign here
        this.address = jsonFromService.address;
        this.city = jsonFromService.city;
        this.state = jsonFromService.state;
        this.zip = jsonFromService.zip;
    }
}

class ContactBase // this is also a code generated class
{
    public firstName: string;
    public lastName: string;

    constructor( jsonFromService: any )
    {
        this.OnInit( jsonFromService );
    }

    OnInit( jsonFromService: any )
    {
        // could use Object.assign here
        this.firstName = jsonFromService.firstName;
        this.lastName = jsonFromService.lastName;
    }
}

// classes that extend the functionality of the code generated classes:
class Address extends AddressBase // subclass simply because I don't want to have to use AddressBase all over my codebase, and then refactor if I ever extend the class
{
}

class Contact extends ContactBase
{
    public Addresses: Address[] = []; // THIS is the customization/extension that cannot be code generated.

    OnInit( jsonFromService: any )
    {
        // note that jsonFromService receives a dto with a array of address info
        super.OnInit( jsonFromService );

        for ( let addr of jsonFromService.Addresses )
        {
            this.Addresses.push( new Address( addr ) );
        }
    }
}

そして、それは私にとってはうまくいきます。 それはそれほどきれいではなく、コードで生成されたクラスに、コードで使用したくない名前を強制します。 しかし、再びそれは機能します。

現時点では、部分クラスに強く反対している人は、部分クラスの概念を誤解しているだけで、部分クラスは部分クラスではないものだと思っているように感じます。

明確にするために：部分クラスは構文構造であり、同じ単一クラスの定義を複数の物理ファイルに分割できます。 ここでのキーワードは「同じ」と「単一」です。

TypeScriptのドキュメントには、部分クラスの誤った定義が記載されています（最初の段落はhttps://www.typescriptlang.org/docs/handbook/mixins.html ）。

実際の部分クラスの概念の例：

ファイル "Point.generated.ts"：

partial class Point {
   readonly x: number;
   readonly y: number;
}

ファイル "Point.codeByHand.ts"：

partial class Point {
  constructor(x: number, y: number) {
      this.x = x;
      this.y = y;
  }

  translate(dx: number, dy: number): Point 
  {
      return new Point(this.x + dx, this.y + dy);
  }
}

それらは「Point.js」にコンパイルされます-そして名前はファイルの名前からではなく、クラスの名前から来ます：

var Point = (function () {
    function Point(x, y) {
        this.x = x;
        this.y = y;
    }
    Point.prototype.translate = function (dx, dy) {
        return new Point(this.x + dx, this.y + dy);
    };
    return Point;
}());

ミックスインは、「部分クラス」として使用される場合（そして、ドキュメント内のこの用語は誤用されていると強く信じています）、実際には多重継承を表しhttps://en.wikipedia.org/wiki/Multiple_inheritance ）。

したがって、ご覧のとおり、実際の部分クラスと多重継承という2つの異なるツールについて説明します。 これらは2つの異なるツールです。 そして、他のツールと同様に、独自のアプリケーション領域があります。 言い換えれば、大工は木槌が利用できないときに木槌の代わりにハンマーを使用するかもしれませんが、ハンマーは適切な道具ではありません。

私見、この議論には未来がないので、やめるべきです。 実際の部分クラスの技術的な問題はまだ見当たりませんが、少なくとも今のところ、チームは実際にそれらを実装することを望んでいません。

TSチームは、可能であればTS固有の機能を実装することを望んでいません。 もっと話し合いたい場合は、ここがより良い場所です： https ：

TC39側に、メールベースのリポジトリではなく、このことについて話し合うためのGitHubリポジトリがあることを願っています：/

@greendimka

現時点では、部分クラスに強く反対している人は、部分クラスの概念を誤解しているだけで、部分クラスは部分クラスではないものだと思っているように感じます。

明確にするために：部分クラスは構文構造であり、同じ単一クラスの定義を複数の物理ファイルに分割できます。 ここでのキーワードは「同じ」と「単一」です。

ここの誰もが部分クラスの定義を誤解しているとは思いません。おそらくJavaScriptのクラスの定義を誤解していると思います。

JavaScriptクラスは、他の広く使用されている言語で見られるクラスとまったく同じであるという印象を受けている場合は、他の人が誤解しているように見えるかもしれません。

ただし、このディスカッションで何度も言われているように、少なくとも1回は明示的に言ったことがあると思います。JavaScriptクラスは、必須の宣言型構造ではありません。

これらは、ステートメントが実行されるまで存在しません。

それらの定義は突然変異に依存しています。

これにより、継承に関しては、すでに脆弱で順序に依存しています。

これは何度も続く可能性があります...

@cosmoKenney

複雑で理解しにくいものがどのように言語に取り入れられたかはわかりませんが、C＃から借用しているため、部分的なクラス構文の優雅さを誰もが拒否しているようです。

私はそれが正しいとは本当に思いません。 誰もがC＃を愛しており、Javaプログラマーも大好きです😛。TypeScriptは、違いがあるために違いはありません。

@aluanhaddad

JavaScriptでのクラスの定義を誤解しているのではないかと思います...

引用以下の場合：TypeScriptについて話しています。
私が言ったように：JavaScriptの構造にコンパイルされるTypeScriptで実際の部分クラスを実装する技術的な問題は見られません。

@greendimka

引用以下の場合：TypeScriptについて話しています。
私が言ったように：JavaScriptの構造にコンパイルされるTypeScriptで実際の部分クラスを実装する技術的な問題は見られません。

この満足度の問題は、TypeScriptクラスのようなものはありません。

ああ少年！ 一部の人々は理由として何かを使用します。
わかりました。TypeScriptにはクラスがありません。 またはTypeScriptクラス。 または何でも。 なんでもいい。

つまり、JavaScriptクラスです。 私は時々衒学者であることに罪を犯しますが、どの機能を簡単に追加できるかを議論する前に、クラスという用語の定義に同意する必要があるため、この区別を非常に具体的に行っています。

私たちがクラスについて話すとき、私たちが同じことを意味するのではなく、それが認知的不協和を引き起こし、相互理解を妨げると思います。

私たちがクラスについて話すとき、私たちが同じことを意味するのではなく、それが認知的不協和を引き起こし、相互理解を妨げると思います。
完全に同意する！

実際、このトピックの最初の投稿は、要求された内容を完全に説明しているため、この議論には将来性がありません:)

@greendimkaはい、TypeScriptには部分的なクラスがないように思われるため、将来性はありません。 私の考えでは、それは良いことです。

しかし、誤解や誤解は良いことではないので、私はまだあなたと話し合っています。

残念ながら、あなたも興味がないようです

A. JavaScriptがクラスとは何かを説明すると、気が変わって、簡単に部分化できることに同意するようになるかもしれません。

B. JavaScriptクラスとは何かについて他の人から学び、反対の視点を理解する必要があります。

これは残念だと思いますが、よろしければこれ以上お話ししません。

私はいかなる議論にも反対していません。 しかし、ここでは、部分クラスは実装されない（少なくとも現在は）と何度か述べられています。 ですから、他のことに集中したほうがいいと思います。 たぶん、TypeScriptは将来変更される可能性があります。
AとBに関連して。私はJavaScriptが嫌いです。 しかし、私はそれを非常によく知っており、もちろん、クラスがその中でどのように「表される」かを知っています。 しかし、この全体的な議論のポイントは、JavaScriptを変更することではなく、「低レベル」のJavaScriptコードを生成する高次言語としてのTypeScriptの機能を向上させることでした。
TypeScriptをC ++に、JavaScriptを機械語に置き換えると想像してみてください。 マシンコードには、C ++に存在するほとんどの概念が欠けています。 しかし、C ++はそれが原因で進化を停止する必要がありますか？ もちろん違います。 一部の古いコンパイラはコンパイルできないため、進化を停止する必要がありますか？ もちろん、いいえ-開発者に新しい機能を提供し、彼らに伝えます：それは新しいコンパイラで動作します-あなた（開発者）はそれを使用するかどうかを決定します。

@aluanhaddad
男ああ男。 方程式のJavascript部分を気にするのは誰ですか？ TypeScriptは上のレイヤーですが、それを表現したい場合もあります。 古い4GLと3GLの議論を覚えていますか？ TypeScriptはJavascriptに対するものであり、4GLは3GLに対するものです。 また、TypeScriptは強力な型を持つES6であるため、部分クラスはTypeScriptのロードマップの範囲外であるという議論はLAMEです。 Mixin、Generics、Modules、Name Spaces、TypeCastingを入手しました。 では、パーシャルクラスでさらに一歩進んでみませんか？

部分クラスに必要なのは、単一のTypeScriptクラスのさまざまな定義すべてを1つの最終的な低レベルの3GLJavascriptクラス定義に統合できるようにするシンタックスシュガーだけです。 最終的なJavaScriptクラス定義に影響はないはずですよね？ Javascriptへの変換の最終成果物がこの議論の一部でさえあるのはなぜですか？ 真剣に。

@cosmoKenney 「型を備えたES.nextだけ」は、JavaScript開発者を変換する大きなセールスポイントです。 もっと何かが必要な場合は、間違った言語を見ていることになります。 代わりにScala.jsを試してみ

編集：ES.nextでは、部分クラスをカスタムモジュールローダーで実装できるという興味深いことに気づきました。 使用する場合

import {MyClass} from './myclass.*'

ローダーは、ワイルドカードに一致する任意のファイルからエクスポートされたすべてのMyClass定義を単一のクラスにマージし、それを提供できます。

@spion私はあなたがそれらをES.next部分クラスとして非常に正しく参照している方法が好きです。 ブラウザなどのESモジュールローダー、またはSystemJSなどのローダーポリフィルは、部分クラスをサポートします。
TypeScriptレベルでこの機能を追加する際の主な問題の1つは、ローダーやパッケージャーなどの既存のツールが破損することです。 一方、ECMAScriptで指定されている場合、これらのツールはすべて機能を実装し、TypeScriptはこれらのツールすべてとの互換性を維持します。

Scala.jsに関しては間違いなくあなたに同意します

@cosmoKenney

Mixin、Generics、Modules、Name Spaces、TypeCastingを入手しました。 では、パーシャルクラスでさらに一歩進んでみませんか？

TypeScriptに見られるミックスインは、TypeScriptが_types_するECMAScriptデザインパターンです。

ジェネリックは型システムの機能であるため、適用されません。

モジュールはECMAScriptの機能です。

名前空間は、ECMAScriptデザインパターンの構文糖衣構文であり、形式化されています。

TypeCastingはTypeScriptには存在しません。

@aluanhaddadなぜこれを実行時のものとして作り続けるのですか？ モジュールローダーと、トランスパイルとは何の関係もないすべてのもの。

+1

@cosmoKenney

@aluanhaddadなぜこれを実行時のものとして作り続けるのですか？ モジュールローダーと、トランスパイルとは何の関係もないすべてのもの。

それは正しくありません。

SystemJSとWebpackのエコシステムを見ると、そうでないことがわかります。

さらに伝統的で堅実なgulpワークフローは、入力ファイルと出力ファイルの間の対応に依存しています。

+1

ツールを使用して基本クラスのほとんどを生成しているため（モデルに変更があった場合に自動化するため）、部分クラスが必要です。 次に、部分クラスを使用して、別のファイルのクラスに機能を追加し、ツール（クラスを自動生成する）によって上書きされないようにします。