TypeScriptチームは、構文と記号/文字プレフィックスの使用についてどう思いますか？

個人的にはひどい見た目だと思いますが、どうやら技術的な限界があります（私にはよくわからないので、使い方は可視性を特定する必要があります）。

TypeScriptが現在のプライベート/保護された構文を失うのを見るのは悲しいことです。これははるかにクリーンで他の多くの言語と一貫性があります。 これは起こりそうですか？ 代替手段はありますか？

これに加えて、 #と@シンボルを切り替える（つまり、デコレータに#を使用する）ことについての話があります。これは明らかにTypeScriptにも影響を及ぼします。 。

それも「ひどい」と思います。 ::バインド演算子のように、実際にはそれほど遠くまでは行きませんでしたが、T39で少し先に進むまで、実装しようとしても延期する価値があると思います。 少しラフな乗り物になるのではないかと思います。 また、すべてのアクセスサイトを書き直す必要があるため、それをサポートするためのダウンエミットはかなり難しいと思います。

私が完全に理解していない理由のために、使用法は可視性を識別する必要があります

主に、使用サイトでプロパティのルックアップ方法を特定する必要があるためです。これは、子孫クラスが祖先のプライベートプロパティについて「知る」必要なしに同じプライベート名を再利用できるように、異なるルックアップアルゴリズムが必要なためです。

提案された構文の利点の1つは、 thisを省略して、 #field直接使用できることです。 さらに、印章はデコレータ（https://github.com/tc39/proposal-private-fields/issues/32）と交換でき、代わりに@が使用されるため、 @field使用します。

「プライベート」ではないキーワードベースのソリューションに人々が満足するとは思わない。

JavaScriptのように一般的なevalをサポートしながら、それを行う良い方法がわかりません-具体的なトークンは、ある程度の差別化を可能にし、TypeScriptのように静的型システムに基づかないプライベート状態をサポートすることを可能にします。 https://github.com/tc39/proposal-private-fields/issues/14でいくつかの代替構文について説明しましたが、TypeScriptの現在の構文は、完全に一般的なJS環境。

主に、使用サイトでプロパティのルックアップ方法を特定する必要があるためです。これは、子孫クラスが祖先のプライベートプロパティについて「知る」必要なしに同じプライベート名を再利用できるように、異なるルックアップアルゴリズムが必要なためです。

JavaScriptが内部でどのように機能するかについてもっと知りたいです。 こことここで説明されているように機能すると思いましたが、明らかにそうではありません。 それがパフォーマンスに大きな影響を与えるとはまだ信じがたいですが、比較できる数字はありません。

この構文はまだ醜いと思いますか？

基本的にはそうです。 さらに、JavaScript構文の残りの部分と矛盾しているだけでなく、他の多くの言語とも矛盾していることがわかりました。

| 言語| 構文| ノート|
| --- | --- | --- |
| C＃| private int x; | |
| C ++ | プライベート：
int x; | |
| Java | private int x; | |
| PHP | プライベート$ x; | |
| Python | __x | 「コメントなし」|
| ルビー| プライベート
defメソッド
＃..。
終了| これはメソッドですが、フィールドはプライベートです
デフォルトでは私は思います。 |
| TypeScript | プライベートx; | |
| Visual Basic | プライベートxAs Integer | |

上記の言語の_one_を除くすべてがprivateキーワードを使用しており、Pythonには実際には「適切な」プライベート状態がないようです。

Pythonを除いて（再び）、どの言語もフィールド宣言またはフィールドアクセスを可視性に応じて異なる方法でフォーマットすることはなく、必要に応じてすべて新しい可視性修飾子を使用できます。

また、 #と@どちらも、デコレータのようなもの、つまり（ケビンの言葉では）「命令型フローの構文的に「外側」」に適していると感じています。

JavaScriptのように一般的な評価をサポートしながらそれを行う良い方法がわかりません

この問題を素人の言葉で説明することは可能でしょうか？ （多分https://github.com/tc39/proposal-private-fields/issues/14にあります）

参照するものがあるように、これらの問題のリストと例を1か所にまとめておくと便利です。

それがパフォーマンスに大きな影響を与えるとはまだ信じがたいですが、比較できる数字はありません。

TypeScriptのような慣例ではなく、本当にプライベートにしたい場合は、そうします。 JavaScriptでプロパティを検索するときはいつでも、プロセスは基本的に次のようになります。

1. 自分のプロパティのインスタンスを見てください。
2. 自分の所有物がない場合は、自分の所有物のプロトタイプを見てください。
3. プロパティが見つからなくなるまでプロトタイプチェーンを上っていきます。
4. 見つかった場合は、プロパティ記述子（書き込み可能、​​取得、設定、構成可能）を処理します
5. 見つからず、読み取られない場合は、 undefined返すか、書き込みを行います。封印または凍結されていない場合は、値を独自のプロパティとして設定します。

名前にパターンがないプライベートを使用すると、独自のプロパティがなくなり、プロトタイプチェーンを上がらない独自のプライベートプロパティのようなものができます。 次に、どちらが参照されているかわからないため、プライベートプロパティにアクセスできる可能性のあるすべての操作についてもそこでそれらを探す必要があります。 通常の方法で検索し、それが見つからない場合にのみプライベートで検索することは非常に危険です。プロトタイプチェーンで何かを見つけたが、プライベートバージョンもある場合はどうなるでしょうか。

最大の課題は、JavaScriptクラスがまだ少し誤った名称であるということです。 それらは本質的に、典型的な継承コンストラクター関数の構文糖衣です。 私が思いついた考えが1つあり、それをtc39 / proposal-private-fields＃14に追加しようと思います。

この問題を素人の言葉で説明することは可能でしょうか？

通話サイトを書き直す必要がある場合は、次のようなサポートはできません。

class Foo {
    private foobar: string;
    baz() {
        const p = 'foo' + 'bar';
        console.log(this[p]);
    }
}

または、構造体のようなeval使用法。 プライベートのインデックスアクセスや評価サポートなしなどをサポートしないことを選択できますが、「なぜわざわざ」することができます。 そこの提案では、これらのほとんどすべてが何らかの形で指摘されていますが、それでも人々は「私はプライベートが好きです」😁。

あなたは自分の財産を持っていないでしょう、あなたは自分の私有財産のようなものを持っているでしょう

記述子にvisibilityアイテムを含む単一のプロパティのセットがある場合、問題は、プロパティが現在のオブジェクトに存在しない場合、昇順するかどうかがわからないことだと思います。プロトタイプチェーン。

通話サイトを書き直す必要がある場合は、...のようなものをサポートすることはできません。

AFAIK、それはとにかくサポートされません（ ref ）。

私はまだ実際には評価のケースに従わない。 プロパティ名が計算された後、実行時にプロパティチェックが行われると思いました。

でも人々はまだ「でも私はプライベートが好き」です

私はそれらの人々の一人にならないように、そして問題を理解しようとしていますが、提案された構文は私を不快にさせます。 =）

さて、私は今、eval / rewriteのケースを理解していると思います。 クラス内の使用サイトは、宣言されたプロパティに基づいて可視性を示すように書き直されます。これは、単純なルックアップでない限り不可能です。

記述子に可視性アイテムを含む単一のプロパティセットがある場合、問題は、プロパティが現在のオブジェクトに存在しない場合、プロトタイプチェーンを昇格するかどうかがわからないことだと思います。

うーん。 しかし、それが現在のクラスに存在しない場合、それは定義上非プライベートではありませんか？ もしそうなら、とにかくプロトタイプチェーンを上に移動する必要があります（通常のパブリックプロパティルックアップと同様）。 privateアクセスのための追加の作業はありません。

（私はおそらく明らかな何かを見逃しています）

しかし、それが現在のクラスに存在しない場合、それは定義上非プライベートではありませんか？ もしそうなら、とにかくプロトタイプチェーンを上に移動する必要があります（通常のパブリックプロパティルックアップと同様）。

いいえ、あなたは上昇したくありません。 プライベートラベルは継承されず、サブクラスはマスキング/名前の衝突を心配することなくプライベートを再利用できます。

@ glen-84あなたが言及したこれらの投稿は両方とも、印章のない私的状態の問題を示しています。 それらの問題の解決策についてのアイデアはありますか？ ルックアップチェーンを複雑にすることは、互換性の面でリスクがあり、JavaScriptを優れたパフォーマンスで実装するのが難しくなり（既存のプログラムが遅くなる可能性があります）、プロキシと二乗することは基本的に不可能であり、一般に、言語のメンタルモデルを大幅に複雑にします（すでに比較的複雑なオブジェクトシステムがあります）。

言語間の比較では、Rubyについて言及しています。 Rubyは私的な状態の良い例だと思います_with_ a sigil-- @ 。 印章なしでgetterメソッドとsetterメソッドを呼び出すことができます。

いいえ、あなたは上昇したくありません。 プライベートラベルは継承されず、サブクラスはマスキング/名前の衝突を心配することなくプライベートを再利用できます。

プロパティが現在のクラスにない場合は、パブリックまたは保護されたプロパティを探すために上に移動することを意味しました。

あなたが言及したこれらの投稿は両方とも、印章のない私的状態の問題を示しています。 それらの問題の解決策についてのアイデアはありますか？

JavaScriptの内部動作を理解していない人として、それを行うのは非常に困難です。

You'd have to somehow encode a "private key" into each lexical environment.

これが何を意味するのかわかりません。 それはなんのためですか？ できませんか？

You'd have to change the semantics of each and every property access (because any property access might result in a private field). Engines are highly optimized around the current property lookup semantics.

高度に最適化されているため、可視性を1回切り替えるだけで、パフォーマンスに大きな影響がありますか？

Would for-in enumerate over these properties?

文脈次第だと思います。 同じクラス内で、はい。 ただし、これはprivateを使用しない理由ではなく、実装の詳細であり、他の言語はおそらくすでにそのような質問に答えています。

Can someone shadow a private property with a normal property lower on the prototype chain? What about the reverse?

おそらく、最初の質問には「はい」（可視性が向上）であり、2番目の質問には「いいえ」です。 繰り返しますが、これはすべて以前に行われたことがありますね。

How do you prevent leaking the names of private fields to clients that shouldn't know that information? This is probably a fatal information leak.

可視性は、パブリックインターフェイスをカプセル化して定義するための単なるツールです。 開発者の99％は、おそらく「情報漏えい」を気にしないでしょう。 そうは言っても、私はここで2つの別々の機能を提案し

All of this runtime stuff is going to be terrible for performance

パフォーマンスが必要な場合は、「非表示/セキュア状態」を使用してください。 ：D真面目な話ですが、どのような種類のパフォーマンスの低下について話しているのでしょうか。 多分誰かがプロトタイプを作ることができます。 =）

Also, we couldn't use such a solution to self-host the built-ins

セルフホスティングビルトイン（それが何を意味するのかさえ理解していれば）は本当にパフォーマンスに悪いのではないでしょうか？ そうでない場合は...「非表示/セキュア状態」を使用し、高レベルのプライベート/保護された可視性は使用しないでください。

ルックアップチェーンを複雑にすることは、互換性に関してリスクがあると思います

私は、これがどのように機能するか/機能する可能性があるかを考える最初の/唯一の人ではありません。 プロパティにアクセスすると、記述子で可視性が確認され、それに応じて応答します。 JSで実際にどのように機能するかがわからなくても、複雑に思えません。 私は本当にJS内部/プロパティルックアップアルゴリズムのクラッシュコースを読む必要があります。 = P

Rubyは印章のある私的な状態の良い例だと思います-@

RubyはCファミリー言語でさえなく、パブリックフィールドはないようですが、ゲッターとセッター（アクセサー）だけです。 現在の私的状態の提案には、同じ汎用（プロパティの宣言）で複数の宣言が並んでいますが、構文は明らかに異なり、一貫性がありません。

とはいえ、私はここでは深遠であり、価値よりもノイズを追加している可能性が高いので、静かにして専門家の合意に達するようにします。

この願いをTC39と話し合い、プレフィックスを回避する方法について他のアイデアを思い付くことができるかどうかを確認します。 個人的には持っていません。 TypeScriptがプライベートフィールドを実装することを決定した場合、それらはまだTC39のステージ1にあるため、変更される可能性があることに注意してください。

TypeScriptチームは、構文と記号/文字プレフィックスの使用についてどう思いますか？

個人的にはひどい感じだと思います...

恐ろしい#構文を取り除くための提案をし

@ shelby3残念ながら、私はそれを現実的な選択肢とは考えていません。 tl; dr、すべてがevalとどのように相互作用するかを心配する必要があります; 印章を含めないと、すべてが「動的すぎて」正しく機能しなくなります。

@littledan私は今、そこでフォローアップし、使用に反対する私の最も強い議論と、 TypeScriptとの互換性を

@isiahmeadows

これは、現在の疑似プライベート実装にほとんど取って代わります[...]また、提案の最も重要な部分は、プライベートプロパティがクラス自体の中でのみ利用可能であるということです。

疑似プライベート実装に取って代わらないことを願っています。 クラス内での可用性だけは実際にはそれほど良いことではないと思います（可用性とはアクセシビリティを意味しprivateは実際にはJavaScriptではそれほどプライベートではありません。 しかし、セキュリティ上の理由は別として、私の意見では、ほとんどの開発者は、ほとんどの場合、契約を定義するためだけにprivateを使用し、アクセシビリティを制御するためには使用しないでください。

たとえば、建築家の観点から、TS privateキーワードとその疑似プライベートな性質について非常に良いことは

• タイプのインターフェースのコントラクトと、それがクライアントによってどのように使用されることを意味するかを表現できること
• コントラクトがコンパイル時にTSコンパイラによってチェックされること
• 特にホワイトボックスの単体テストでは、実行時に契約に意識的に「違反」する可能性があります。

実行時のプライベートプロパティのアクセシビリティは、テスト対象のクラスにプライベートフィールドを設定するだけでプライベート状態を挿入できるため、anyキャストの代わりにブラケット表記を使用することをお勧めします。リファクタリングサポート）、例：

let instance: ClassUnderTest = new ClassUnderTest();
instance["_privateField"] = "My injected state";

特定の（プライベート）状態のクラスを設定するためだけに複雑なテストコードを作成する必要はありません。
疑似プライベートプロパティのもう1つの利点は、モンキーパッチに不可欠なことです。

@ about- codehttps：//github.com/tc39/proposal-private-fields/issues/33を参照して

TypeScriptコミュニティがすべてのprivate variable行をprivate #variable喜んで変更するとは思わない。

TypeScriptの観点から、私たちのほとんどは、優れた言語（インテリセンス、ビルド時エラー、タイプ、さまざまな糖）の素敵で甘い幻想に満足しています。 これらの幻想は私たちにより良い開発体験を与え、私たちはより良いコードをより速く書きます。 これが、ESNextトランスパイル以外にTSを使用する主な理由ですが、後者の場合はBabelがあり、それが優れています（または、少なくとも最後にチェックしたときの方が優れていました）。

私は、ソースファイルの構文糖衣構文よりもプライベート変数から実際に何かを求めている少数の人々について話しているのではありません。 私はそれらの人がおそらくネイティブコードに近い、より強力な何かを必要としていると思います。

しかし、残りの私たちのために：私たちは本当にJSプライベートを必要としません。 C ++、Java、C＃などで使用したのと同じように、シンプルで簡単なprivate convenient変数が必要です。

私たちにとって苦痛ではない解決策に投票してください。 たぶんソフトプライベート？ 印章をプライベート#variableたいのではないかと思うからです。 それとも、TS privateとESプライベートは異なる概念でしょうか？ ぶさいくな。

@igabesz

TypeScriptコミュニティがすべてのprivate variable行をprivate #variable喜んで変更するとは思わない

実際、その提案では、 privateは不要です。 代わりに、 #印章が、競合することなく完全に置き換えられます。

しかし、残りの私たちのために：私たちは本当にJSプライベートを必要としません。 C ++、Java、C＃などで使用したのと同じように、シンプルで簡単なプライベートの便利な変数が必要です。

TypeScriptのプライベートは、ほとんどのオブジェクト指向言語と同様に、ソフトプライベートです。 Javaのプライベート変数でさえ、エスケープハッチでアクセスできるため、技術的にはソフトプライベートです。 JS privateは、 thisインスタンスのプライベート状態に引き続きアクセスできることを除いて、クロージャを使用するのと同じです。

私たちにとって苦痛ではない解決策に投票してください。 たぶんソフトプライベート？ 印章のプライベート#variableが必要だとは思えないからです。 それとも、TSプライベートとESプライベートは異なる概念でしょうか？ ぶさいくな。

それらは異なる概念になりますが、一般に、エスケープハッチが実際に役立つことはめったにありません。 主な例外はオブジェクト検査（開発者ツール、Node.js util.inspect ）ですが、ほとんどはホスト定義であり、すでに特権ネイティブAPIを使用しているため、仕様に追加する必要はありません。

さらに、ESがプライベート状態を標準化すると、TSはそれを採用し、次のメジャーバージョンで削除される独自のソフトプライベートメカニズムを廃止する可能性があります。 これは常にESの厳密なスーパーセットであり、ES自体が進化するにつれて、必要に応じて機能を追加（非同期関数）、変更（クラス）、および/または非推奨（ /// <amd-dependency /> ）して、それ自体を厳密なものとして維持します。スーパーセットであり、現在の仕様を複製しません。

さらに、ESがプライベート状態を標準化すると、TSはそれを採用し、次のメジャーバージョンで削除される独自のソフトプライベートメカニズムを廃止する可能性があります。

😭

さらに、ESがプライベート状態を標準化すると、TSはそれを採用し、次のメジャーバージョンで削除される独自のソフトプライベートメカニズムを廃止する可能性があります。

これはTSチームの立場ではありません。 近いうちに廃止する予定はありません。
プライベート状態の提案が正しい状態に達した場合、TSはそれを実装します。 TSが今日それらを実装しているので、これがプライベートに影響を与えるとは思わない。

@mhegazyわかりました。 私は正直に立っています。 （それは知識に基づいた推測でした、ところで。）

Class Fields Proposalは現在ステージ2にあるので、TypeScriptチームがこれを検討し、EcmaScript標準に従う準備ができてうれしいです💯

プライベート状態の提案が正しい状態に達した場合、TSはそれを実装します。

@mhegazyステージ3を実装するのに適切な時期ですか？

編集：私は私の答えを見つけたかもしれません😄

@styfleは、実装に関する現在の考慮事項について説明している設計会議ノート（＃16415）の説明を参照してください。

ステージ3は実装するのに適切な時期ですか？

はい。 この機能で可能なさまざまな設計の調査を開始しています。

クラスフィールドの提案は現在ステージ3にあります。 （1か月前の時点で）

クラスフィールドの提案は現在ステージ3にあります。 （1か月前の時点で）

クラスフィールドがステージ3に到達する間、プライベートメソッドとアクセサーはそれから続き、ステージ2にあり、昨日ステージ3に移動しました。クラスのプライベートメンバーに対処するために必要なものはすべてステージ3にあります。

しばらくの間ステージ3になっているので、 #[field]構文の採用に関するTSチームの立場/進捗状況に関する更新はありますか？ 個人的に私はそれが本当に嫌いで、TSの既存のprivateキーワードを大いに好みますが、同時に可能な限り標準に近づけたいと思っています。

個人的に私はそれが本当に嫌いで、TSの既存のプライベートキーワードを大いに好みます

私も、それはとても醜いです

しかし、 @ mhegazy私はこれを（試して）やりたいのですが、私はできますか？

解析は悪くないはずですが（ほとんどトークンであるほとんど新しい修飾子）、タイプチェックは面倒です（何らかの方法で比較する必要がある2種類のプライベートがあるため）。ダウンレベルの放出はひどいものです（実際のランタイムプライバシーのダウンレベリングは大きな変革であるため、 プライベートスタティック（および場合によってはデコレータ）も進歩するまではまだ少し不完全です（それらがすべてどのように相互作用するかを考えると、一度にすべてを追加する方が良いかもしれません）。

言うまでもなく、ここにはたくさんあります。

@weswighamわかりました、あきらめます😂

これは、私（ @ Neuroboy23など）がプライベートフィールドの実装を実験することになるという

更新：進行中の作業はこちらです。

はい。 この機能で可能なさまざまな設計の調査を開始しています。

#構文も好きではありませんが、この構文の背後にある技術的な理由は理解しています。 @mhegazy新しい提案を実装した後、TypeScriptチームが本当にやりたいことは、TypeScriptがnamespace 、 privateなどの廃止された実装で何をするのかを考えることです。同じまたはほぼ同じことを行うためのより良いes-standardの方法があるからではありません。

また、 protectedについて数セント追加したいと思います。 いつかprivateキーワードを削除/非推奨にする場合（今はうまくいけば）、 protectedキーワードでも同じことをしても大丈夫だと思います。 ほとんどの人が同意できないことは知っていますが、そうです、追加の可視性スコープが便利な場合もありますが、全体的な価値はそれほど高くありません。

@pleerock 、

これは私がTypeScriptから見ると期待するものです：

class Example {
    private a = 1;
    #b = 2;
}

Emit（ESNextをターゲットにする）：

class Example {
    a = 1;
    #b = 2;
}

Emit（ESNextをターゲットとし、ESプライベートフィールドとしてプライベートとしてマークされたフィールドを発行する新しいコンパイラオプションを使用）：

class Example {
    #a = 1;
    #b = 2;
}

これは下位互換性があり、クリーンな構文でESプライベートフィールドを使用できるようにする必要があります。

@ glen-84もちろんそうでしょう、私は時代遅れのキーワードと構文に関する長期計画について話していました

構文やキーワードを廃止する予定はありません。

また、 privateを#にトランスパイルするオプションはないと思います。予想される動作は異なります。 #はハードランタイムプライバシーですが、 privateは単なる設計時のプライバシーです。

@weswigham私もそう思います。 @RyanCavanaughええそれは期待された答えでした。 しかし、それでも私は、新しいユーザーが最新のecmascriptの提案で時代遅れになったため、名前空間/プライベートキーワードの使用を避けるために少なくともいくつかの戦略を適用します

人々は一般的に、私たちがもちろん更新するドキュメントを読むことに基づいてこれを理解します。 module foo {はまだ言語のままですが、 namespace foo {より前の非常に古いコードベースを除いて、基本的にはもはや実際には見られません。

@RyanCavanaughそれを聞いて#代わりにprivateを使い始めるでしょう、そしてこれは名前空間の例よりも大規模になる傾向があります

また、プライベートを＃にトランスパイルするオプションはないと思います。予想される動作は異なります。 ＃はハードランタイムプライバシーですが、プライベートは設計時のプライバシーです。

ドー。 不幸な構文を避けるために、オプションでハードプライバシーにもprivateを使用できることを望んでいました。

とにかく、私の（現在の）ユースケースにはおそらくソフトプライベートで十分です。

この機能は巨大であり、バージョン3は人々に新しい#構文を使い始める良い機会に見えるので、TypeScriptの今後の3バージョンにこの構文サポートを含めるのは素晴らしいことだと思います。

編集：くそーバージョン3がすでにリリースされていることを忘れました。

参考までに、TC39プロポーザルのレポにはプライベートフィールド/スロットなどに関する最近のチャーンがいくつかあるため、現在の形式のプロポーザルがそれを実現するかどうかさえ定かではありません。 ここにいくつかの関連する問題があります：

• https://github.com/tc39/proposal-class-fields/issues/100
• https://github.com/tc39/proposal-class-fields/issues/106

私はTC39ではありませんが、皆さんへの個人的な提案は、最初に構文が再び固まるのを待ってから（おそらくステージ4を待って）、それを実装することです。

FWIW tc39 / proposal-class-fields＃100での議論は、特に何かを示すものとは解釈しません。 #は一見きれいではありませんが、好ましい構文形式は提案されておらず、人々が望んでいると思われる唯一の構文は明らかに機能しません。 ある種のプレフィックスシジルが必要であり、 this.somePropをプライベートにするすべての試みは失敗する運命にあります。

私はそれがかなり否定的に聞こえることを理解していますが、率直に言ってそれが私の意図です-それらのスレッドの不満者の誰も、現存するスレッドまたはFAQで扱われるコア技術的問題に有意義に関与していません。 そのレポのスレッドを読み通し、印章が必要な理由の長い正しい説明を見るのは気のめいるようです。

エンドゲームが、ハードランタイムプライバシーを本当に必要としない限り、ことである場合、それはパフォーマンスとデバッグ可能性の観点からWebにとっておそらく良い結果です。

私はそれがおそらく言及するのに理想的な問題ではないことに同意しますが、他の
tc39 / proposal-class-fields＃106は、おそらくはるかに指標的です-あります
とりわけ弱いマップを代わりに使用することについての真剣な議論。
プロキシ相互運用は明らかに最悪です。

イシアメドウズ
[email protected]
www.isiahmeadows.com

15:38時月、2018年7月30日には、ライアン・キャバノー[email protected]
書きました：

FWIW私はでの議論を解釈しません
tc39 / proposal-class-fields＃100
https://github.com/tc39/proposal-class-fields/issues/100
特に何かを示します。 ＃最初はきれいではありませんが、
望ましい構文形式は提案されておらず、唯一の構文は
人々が望んでいるように見えるのは明らかに実行可能ではありません。 プレフィックスが必要です
ある種の印章とthis.somePropをプライベートにするためのすべての試み
失敗する運命にあります。

私はそれがかなり否定的に聞こえることを理解していますが、率直に言ってそれが私の意図です-
それらのスレッドの不平を言う人は誰も意味のあることに関与していません
現存するスレッドまたはFAQで対処されている主要な技術的問題。 これは
そのレポのスレッドを読み通して長く見るために一体として気のめいる
印章が必要な理由の正しい説明は、
接地。

エンドゲームが、本当にプライベートフィールドを使用しない限り、
ハードランタイムプライバシーが必要です、それはおそらくウェブにとって良い結果です
パフォーマンスとデバッグ可能性の観点から。

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

WeakMapsの使用についてはいくつかの議論がありますが、それがProxyとの相互作用をどのように改善するかはわかりません。 プライベートクラスの機能がどのように機能するかについて別のアイデアを持っているTC39メンバーを招待して、フィードバックのために委員会に提示します。 現在、この提案はステージ3にあり、理論的には委員会のコンセンサスポジションを表しています。 他の設計が可能であっても、多くの人々がこの機能を有効にするという共通の目標を達成するために妥協しました。

私は、プロキシを使用してオブジェクトの変更を監視する方法と、それがプライベートフィールドとどのように相互作用するかについて、フレームワーク間のディスカッションを整理するように取り組んでいます。 会話に参加したい場合はお知らせください。

@RyanCavanaugh

FWIW tc39 / proposal-class-fields＃100での議論は、特に何かを示すものとは解釈しません。 #は一見きれいではありませんが、好ましい構文形式は提案されておらず、人々が望んでいると思われる唯一の構文は明らかに機能しません。 ある種のプレフィックスシジルが必要であり、 this.somePropをプライベートにするすべての試みは失敗する運命にあります。

これについては遅れていますが、実際にはthis->var構文を提案する提案があり

確かに、この提案はおそらく死んでいます（「委員会は熱狂していなかった」が私が見つけた唯一の理由です）。 しかし、別の構文が実際に提案されており、すべての利害関係者がこれらに精通し、認識していることを願っています。

privateを実行時に強制されるある種の_soft_プライベートにトランスパイルするコンパイラオプションがあると便利だと思います。 真のハードプライベートを必要とするユースケースは特に一般的ではないと思います。したがって、 #構文が嫌いな場合でも、ほとんどの人はprivateに固執する傾向があると思います。 ただし、コンパイル時のみのプライベートは_too_ソフトIMOです。 また、そのようなオプションは、プライベートの可能なバリアントの数を減らすのに役立ちます...開発者がこれを自分で実装することを任されている場合は、これらすべてを持つことができます：

class Demo {
  private a

  #b

  <strong i="9">@reflect</strong>
  #c
}

したがって、新しいオプションを有効にすると、 private aが<strong i="13">@reflect</strong> #aにトランスパイルされることを提案します。ここで、 @reflectは、コミュニティでサポートされているAPIを介してプロパティを反映できるデコレータです。 標準のデコレータライブラリについての話が@reflectデコレータ（または私たちがそれと呼びたいもの）は将来標準化される可能性があります。 そのための良い候補になると思います。

私の提案の主な欠点は、パフォーマンスへの影響だと思います。 いつの日かJSに、それらを最適化するためにネイティブに実装された標準のデコレータがいくつかあることを期待できますが、当面の現実は、 <strong i="19">@reflect</strong> #xが単なる#xよりも遅くなることです。 しかし、私はこれをオプションとして提案しているだけであり、おそらくデフォルトで無効にする必要があります（下位互換性の理由からも）。

@MichaelTheriot

これについては遅れていますが、実際にはthis-> var構文を提案する提案があります。

確かに、この提案はおそらく死んでいます（「委員会は熱狂していなかった」が私が見つけた唯一の理由です）

委員会は、クラス1.1の提案ではなく、現在の提案を承認するための十分に考慮された理由をたくさん示しています。たとえば、

@mbrowne

私はそれを逃したかもしれません。 クラス1.1の問題ページは半年間非アクティブであり、あなたがリンクした例でさえ私のコメントの1か月後に書かれました。

参考までに、数か月前にリンクしたスレッドでこれについて言及しました。 ここでの私のコメントは、代替構文が提案されていないという誤解に対処するためだけのものでした。関係するすべての関係者はそうではないことを認識しておく必要があるからです。

編集：私のコメントは、TypeScriptが何か違うことをすることを示唆していません。 提案の参照された問題に関する誤った情報を訂正することは有用であると私は信じています。

@MichaelTheriot代替案の通知が必要な当事者は、この会話に関与する当事者ではありません。 TypeScriptは、承認される予定の提案に従います。 私の意見では、代替構文が提案され、採用されていないという事実は、この会話にはあまり役立ちません。

やあみんな、それが役立つ場合に備えて、私はランタイム保護/プライベートメンバーの私自身の実装を共有したいと思います：

lowclass参照してください。

ランタイムのパブリック/保護/プライベートメンバーのあらゆる種類の使用法を示す広範なテストファイルを確認してください。 実装は長くはなく、最小限の保護/プライベート機能のみを持たせるために一部の機能を省略できます。

ノート：

• WeakMapsを使用して、保護された/プライベートな状態を保存します。
• 私が見た他の実装とは異なり、同期呼び出しスタックトレースに依存しないため、callbacks / promises / awaitを使用する非同期コードで機能します。
• ゲッター/セッター（スーパーコールを含む）で動作します（テストを参照）。
• ネイティブのsuperで動作するか、ES5のSuperヘルパーを使用します（テストを参照）。
• constructorメソッドをサポートします（テストを参照）。
• 組み込みクラスを拡張する機能（Dateを除くが、それは不可能だと言われているが、確認したい。テストを参照してください。ネイティブのカスタム要素を操作する場合）。
• 通常のネイティブclassを拡張する機能（テストを参照）。
• ネイティブのclassラップして、保護されたプライベートな機能を提供します（テストを参照）。
• ネイティブのclass esの代わりにES5スタイルのfunctionクラスを記述します（テストを参照）。
• パフォーマンスを最適化するための多くの余地（スーパー/保護/プライベートヘルパー呼び出しのキャッシュとルックアップアルゴリズムの最適化）

テストを実行するには：

npm install
npm test

Babelの実装の詳細と問題については、 https：//github.com/babel/proposals/issues/12およびhttps://github.com/babel/babel/issues/8421も参照してください。

みなさん、こんにちは。

まだ完成していないプライベートクラスフィールドの仕様を実装しないでください。 問題があります。

このスレッドをお読みください。

これを読んだ人は、他の構文のアイデアを見て（よく読んでください、もっとあります）、あなたの意見を表明することをお勧めします。

feここに別のスレッドがあります（現在の# IMHOよりも優れた構文のアイデアがあります）。

すでにパブリック/プライベート/プロテクトを広く使用しているJavaScriptコミュニティがある場合、JSプライベート/プロテクトの未来を形作るのに役立つ大きなチャンスがあるのはTypeScriptコミュニティです。

そのため、プライベートクラスフィールドはV8v7.2とChrome72で出荷されています。プライベートフィールドの提案の実装を開始する予定はありますか？

@ ChrisBrownie55パブリックフィールドが出荷されています。 プライベートではありません。

@jhprattそれは私の悪いことですが、Chromeチームは近い将来プライベートで出荷することを計画しているようです

参考： https ：//v8.dev/blog/v8-release-72#public -class-fields

V8 7.2の時点でパブリッククラスのフィールドを出荷していることを文書化していますが、プライベートフィールドに関してはこれがあります（私の強調）：

プライベートクラスフィールドのサポートは、将来のV8リリースで計画されています。

@isiahmeadows私は実際にGoogleの開発者ブログの別の投稿を参照していました。

結論

パブリッククラスフィールドはV8v7.2およびChrome72で出荷されます。プライベートクラスフィールドはまもなく出荷される予定

Googleの開発者ブログの記事へのリンク

これらの記事は@mathiasbynensとました。これらの記事は、必要に応じて説明を求めることができます（ただし、これらの投稿はそれぞれかなり明確だったと思います）。 V8での実装の仕上げに取り組んでいるcc @ gsathyaと@joyeecheung 。

とにかく、2019年1月のTC39会議は、提案に関するコンセンサスのさらに別の再確認とともに、私的分野と方法の提案の代替案を再考する1年半を締めくくった。 現在のバージョンは安定していて、TypeScriptを使用する準備ができていると考えられます。

Chromeはプライベートクラスフィールドをリリースしました🎉
これらは、現在_canary_ビルドでリリースされているChrome74にのみ含まれています。

Chrome74でプライベートクラスフィールドを出荷しました。 今すぐChromeカナリアでお試しください！
—Twtiter経由のSathyaGunasekaran

プライベートクラスフィールドの特定の実装を選択する（または実装する）ことについて、私たちがここにいる場所を知っている人はいますか？ @trusktrがロークラスを推奨しているのを見ましたが、「

明らかにそうではありません。 プライベートフィールドはプロトタイプチェーンを歩きません（他のオブジェクトがそれらを見ることができるため、プライベートではないため）

プライベートフィールドはWeakMapsにトランスパイルすると思います（Babelと同じように、フィールドごとに1つのWeakMap）。 #構文をサポートするブラウザーのみを対象としている場合は、最終出力に

パフォーマンス上の理由から、開発者が将来の互換性のために#構文を使用できるようにするオプションを検討する価値があるかもしれませんが（より多くのブラウザーがそれをサポートする場合）、実際には__ts#特別なプレフィックスを持つパブリックプロパティにトランスパイルします#構文を使用する開発者は通常、コンパイル時と実行時の両方のプライベートであると想定するためです。 ただし、実行時のパフォーマンスを最大化し、その間にコンパイル時のプライベートだけに満足したい場合は、パフォーマンスを低下させることなく、新しい構文の使用を開始するのに適した方法になる可能性があります。

実装の進捗状況に関する更新はありますか？ おそらく、テストしてフィードバックを提供するために構築できるPRですか？

@jhpratt確かに！ このPRでブランチをチェックアウトすると、プライベート名のインスタンスフィールドをテストできるようになります。 メソッドとアクセサーは進行中です。

この作業を上流に進めたいと考えています。 この前提条件のPRがマージされるとすぐに、このリポジトリ（Microsoft / TypeScript）に対して変更をPRできます： //github.com/Microsoft/TypeScript/pull/30467。

フィードバックは大歓迎です。

「PrivateInheritance」が仕様の一部であるかどうかはわかりません。

ちなみに、100％真のプライバシーを実現するために、その機能をロークラスに削除する予定です。 私は実際にはそれを本当に必要としませんでした、それはもっと実験でした。

ちなみに、「私的継承」に関する理論が役立つ可能性がある場合に備えて、ここに投稿したいと思います（おそらく、興味深い、または他のアイデアの火付け役になる可能性があります）。

「プライベート継承」（現在のバージョンのロークラスに見られるように）は、サブクラスがスーパークラスから継承されたプライベートメソッドを使用できることを意味しますが、メソッドは、あたかもそのサブクラスのスコープ内のインスタンスのプライベートプロパティに変更のみを適用します。サブクラスには、独自の定義でプライベートメソッドとして定義されたメソッドがありましたが、サブクラスは、スーパークラスまたは兄弟クラスのスコープ内のインスタンスのプライベートプロパティを変更できません。

比較すると、「保護された継承」では、サブクラスはそれ自体のインスタンスまたはスーパークラスインスタンスのプロパティを変更できますが、兄弟クラスのプロパティを変更することはできません。 保護された継承では、サブクラスはすべてのスーパークラスが表示できるプロパティを変更します（スーパークラスはすべて同じプロパティに対して読み取り/書き込みを行います）。

言い換えると、「プライベート継承」の概念では、各クラスにプライベートスコープがあり、保護されたメソッドがクラス階層全体の単一のスコープで動作する保護されたメソッドとは対照的に、継承されたプライベートメソッドはローカルクラススコープでのみ動作します。

それが理にかなっているかどうかわからないので、現在のecmaproposal-class-fieldsプライベートフィールド機能を使用して記述した場合、「プライベート継承」がどのようなものになるかを説明する簡単なコード例を次に示します。

プロポーザルクラスフィールドには「プライベート継承」がないため、以下は機能しません（そして、真のプライバシーを維持するために、これが望ましいことに同意します）。

class Foo {
    test() {
        this.#privateMethod()
    }

    #foo = 'foo'

    #privateMethod() {
        console.log(this.#foo)
    }
}

class Bar extends Foo {
    test() {
        // This does not work, no private inheritance:
        this.#privateMethod()
    }

    // #foo is private only inside Bar code, it is NOT the same #foo as in Foo
    // scope.
    #foo = 'bar'
}

ロークラスでは、「プライベート継承」は、エディターでコピー/貼り付けを使用して、同じことをエミュレートする次の非DRYコードを記述することと同じです。

class Foo {
    test() {
        this.#privateMethod()
    }

    #foo = 'foo'

    #privateMethod() {
        console.log(this.#foo)
    }
}

class Bar extends Foo {
    test() {
        // This does not work, no private inheritance:
        this.#privateMethod()
    }

    // #foo is private only inside Bar code, it is NOT the same #foo as in Foo
    // scope.
    #foo = 'bar'

    // copy the method over by hand (because there's no private inheritance):
    #privateMethod() {
        console.log(this.#foo)
    }
}

どちらの例でも、 #foo変数は各クラスに固有の変数です。 #foo変数は1つではなく、2つあります。 それぞれが同じクラス定義のコードによってのみ読み取りおよび書き込み可能です。

この方法は、この方法が使用されている範囲で動作_but_ lowclassでは、民間の継承は、再利用のプライベートスーパークラスのメソッドに私たちをことができます。 したがって、上記の例のように、スーパークラスメソッドをコピーしてサブクラスに貼り付けたようになりますが、クラスごとに2つの別々の#foo変数があります。

ロークラスでは、スーパークラスで#someMethodが使用されている場合、スーパークラスの#fooで動作します。 場合は#someMethod 、サブクラスのスコープ内で使用されている、それは上で動作#foo 、いないサブクラスの#fooスーパークラスの！

それがコンセプトの説明になることを願っています。たとえ使われなくても、どんな種類のアイデアを生み出すのにも面白いか役立つかもしれないと思います。

現在Chromeの安定したチャネルにあるため、開発者はネイティブで使用できます。 私はVSCodeのためにこの問題に主に興味があります-バニラ.js javascriptを書くとき、VSCodeはそれをエラーとしてマークします。 Typescriptに追加するかどうかの議論とは別に、VSCodeのVanilla JSのプライベートクラスフィールドのサポートを追加する方法はありますか？

個人的には、TSがステージ4に到達する前に、それらのサポートを追加する必要があるとは思いません。TSには、今のところ十分に機能するコンパイル時のプライベートがすでにあります。 それがステージ4に達した後、私はそれが理にかなっていることに同意します。 （議論の中で時折流動的な発作があったので、私はまだそれがプライムタイムの準備ができているとは思わないでしょう。）

更新：ノード12の安定版でもサポートされています。 また、Babelには、この構文を変換するためのプラグインがあります。 開発者は、ステージ4の提案になる前に機能を使用することがよくあります。 Vanilla JS（非ts）でこの構文のサポートが追加されるか、 jsconfig.jsonを介してこの構文を有効にして、VSCodeで使用時にエラーが表示されないようにする方法が必要です。 VSCodeリポジトリは、JSサポートがTypeScriptによってサポートされており、この問題を参照していると述べています。

TypeScriptがこの機能をまったくサポートしないのは意味がありません。これは、主要なブラウザーとノードの実稼働環境にすでに存在しているためです。 これは、TypeScriptが今すぐすべてを完全に固め、デフォルトの機能としてリリースする必要があるということではありません。

TypeScriptは、この機能が実験的であり、ステージ3とステージ4の間で変更される可能性があることを示すフラグの下にプライベートフィールドを導入することをお勧めします。

たぶん、セマンティクスなしで最初に構文サポートを実装できますか？

たぶん、セマンティクスなしで最初に構文サポートを実装できますか？

タイプチェック/インテリセンスの場合、何らかのセマンティクスが必要だと思いますが、 BigIntようなダウンレベル変換のサポートはありません（ esnextのみ使用できます）。

fwiw、実装のフィードバックにより、ステージ3でのみ変更される可能性があります。 Chromeが出荷していることを考えると、変更が行われる可能性はほとんどありません。

@ ChrisBrownie55この機能がまだ実装されていないことは意味がないと思います

これは進行中のようです：
https://github.com/microsoft/TypeScript/pull/30829
（これは明らかにhttps://github.com/microsoft/TypeScript/pull/30467で待機しています）

そうです、＃30829は、リベース後にマージの準備ができています。いくつかの機能ゲーティングを法として、プライベート名のメソッドで爆発します。

みんな、主要なブラウザがこの機能を実装したからといって（それがどのように感じられるか、それで遊ぶなど）、誰もがそうすべきだとは限りません。

議論の中で時折流動的な発作があったので、私はまだそれがプライムタイムの準備ができているとは思わないでしょう

@isiahmeadowsが述べたように、クラスフィールドの提案は論争に満ちており、多くの人々がそれを嫌っています。 現在のプライベートフィールドに対するコミュニティの嫌悪感を示すいくつかの問題があります。

• https://github.com/tc39/proposal-class-fields/issues/100
• https://github.com/tc39/proposal-class-fields/issues/150

私が言語の実装者である場合、これについて心配します。何千人もの（知らない）開発者が問題のあるものを使い始めることを許可することにしたので、非常に嫌われている機能がリリースされる（石に設定される）責任を負いたくありません。プロダクションコードの機能。

プライベートフィールドは、ES6以降に導入されたすべての機能の中でおそらく最も物議を醸しています。 言語の実装者は、機能を石に設定する前に、嫌いなものを考慮に入れるのが賢明だと思います。

@trusktrこれは物議を醸す機能かもしれませんが、開発者がそれを使用するかどうかは、ツールではなく開発者に任された決定でなければなりません。 主要なブラウザは、「それで遊ぶ」ためではなく、本番環境で使用するために出荷しました。 また、最も人気のあるサーバー側JSランタイムであるNodeにも同梱されています。 繰り返しになりますが、構文がTypeScriptに到達するかどうかについてはあまり関心がありませんが、構文がVSCode（TypeScriptによってサポートされている）上のJavaScript言語サーバーによってサポートされているかどうかについてはもっと関心があります。

Nodeでも出荷されています

NodeのJSエンジンを維持するChromeリリースの副作用としてのみ。

これは物議を醸す機能かもしれませんが、開発者がそれを使用するかどうかは、ツールではなく開発者に任された決定でなければなりません。

それはあなたのような開発者の場合かもしれません（たぶんあなたはただ製品をリリースする必要があります、そしてあなたはあなたが持っているどんなツールでも働くでしょう、それは実際あなたがその点ですべきことであり、そして多くの雇用された開発者がします）。

与えられたツールを使おうとしているだけで、クラスフィールドに関連付けられているフットガンについて知らない開発者もたくさんいます。

また、言語自体と保守可能なコードの将来を気にし、特定の間違いを元に戻すには手遅れになる前に、正しく進化することを望んでいる開発者もいます。

新しいプライベートフィールドは#構文を使用しているため、代わりにprivateキーワードを使用して修正する余地があります。

TSは本当に標準の100％に従う必要がありますか？ 委員会がthisGlobalまたは#privateLolでコミュニティに反対していることはすでに知っているので、手遅れになる前にGoogleがJavaScriptを独占していないと言う時が来たのではないでしょうか。

@TeoTNプライベートフィールドはGoogleのものではありません。 他のすべての最近の標準と同様に、TC39を介して進められています。

明確にするためのいくつかのポイント：

• まだ完全にベイクされていないES機能を急いで出荷しているわけではありません（オプションの連鎖、null合体、スロー式、パイプライン演算子、nameofなども参照してください）。
• 逆に、承認されたES機能の実装と出荷はオプションではありません
• 特定のものが好きではない多くの人々はどちらの方法でも要因ではありません
• プライベートフィールドは、後の設計変更（または取り消し）が深刻なユーザーの苦痛を引き起こすことなく実装しても安全であると確信した場合、TSに含まれます。

@RyanCavanaugh説明とすべての素晴らしい仕事に感謝します！ 小さな提案：ESは継続的に進化しており、多くの機能が開発されています。どの段階、つまり段階4であるかというルールを設定するのは良いことだと思います。 ステージ3？ またはその間のどこか？ -ES機能を含めることができます。 そうでなければ、この種の議論は他の機能のために将来何度も繰り返される可能性があります。

プライベートフィールドは完全に焼かれたと合理的に言うことができます。

@kkimdevステージ4はそれが行く限りです。 それは標準の一部になったことを意味します。

完全にベイクされていないES機能

不思議なことに、完全に焼き付けられたES機能とは何ですか？ この例で「完全に焼き上げた」とはどういう意味ですか？

承認されたES機能の実装と出荷はオプションではありません

TypeScriptの目標がバニラJSよりも単純な型であることを考えると、これは完全に合理的です（したがって、 namespaceようなものは現在の目標に関して悪い選択であり、 enumも議論の余地があります）。

TypeScriptには、すべての主要なエンジンが特定の機能を満場一致で出荷するまで機能の出荷を待つ（または待たない）ことで、言語仕様を左右するコミュニティを支援する（または支援しない）力があります。

TSチームのメンバーはTC39に座っているため、非効率のようです。そのため、最初に誰かが出荷する前に、ステージ3の機能については、すでにコンセンサスの一部になっています。これも含まれます。

私はTypeScriptの設計上の決定が、出荷されるものを保守的にすることを本当に大切にしています。 多くの場合、開発者に保証された安定性を与えるために、もう少し待つのが理にかなっています。 私は私的分野に関する政策決定に非常に満足しており、それらについて@DanielRosenwasserと頻繁に連絡を

これらの言語設計の決定について議論するのに最適な場所は、提案リポジトリ、TC39会議、およびこの作業に特化した他のコンテキストであると思います。 プライベートフィールドとメソッドの提案については、 @ trusktrと幅広く

最終的には、TC39は言語設計を継続する必要がある場所であり、TypeScriptリポジトリは、機能の優先順位や実装の詳細、機能のタイミングの判断など、他の側面について話し合う場所になる可能性があると思います。出荷するのに十分安定しています。

TypeScript Intellisenseは、VS CodeでのJavaScript構文の強調表示と、VS Codeリポジトリで見つけた2つの構文ハイライトの問題（Microsoft / vscode＃72867およびMicrosoft / vscode＃39703）を強化しているため、ここでTypeScriptへの実装について説明します。これがJavaScriptファイルのエラーにならないのはクールだと言って貢献させてください。

完全に有効なJavaScriptは、VS Codeでエラーとしてマークされます。これは、別の言語のコンパイラーが、構文がサポートされるかどうかを決定しているためです。 :-)

TypeScriptがこれを決定する前に時間を割いても問題はありませんが（実際にはサポートしています！）、これはJavaScript構文の強調表示に影響を及ぼし、簡単に修正したり、ローカルでさえ作業したりすることはできません（パッチを適用するものがないため（AFAIK）、シンタックスハイライトの文法ファイルにパッチを適用します。

私はTypeScriptチームに所属していませんが、彼らはこれの実装に積極的に取り組んでおり、現時点でプライベートフィールドがサポートされることに疑いの余地はないと思います。 https://github.com/microsoft/TypeScript/pull/30829を参照して

作業中であることを確認できます。TSチームと協力しており、現在リベースをまとめています。 TS（および拡張機能としてLanguage Server）のプライベート名のフィールドに興奮しています。

https://github.com/microsoft/TypeScript/pull/30829でこれを実装してくれたブルームバーグの協力者に感謝し

ちょっと、そこ。 これについて別の問題を作成したい場合は、そのように言ってください。 この問題の原因となった特別な#private PropertyDeclarationを発行する理由を知りたいと思います。

たとえば、次の宣言が生成されます。

// index.d.ts
declare class Foo {
    #private;
    // ...
}

...入力が与えられた：

// index.ts
class Foo {
    #name: string;
}

私は最初にそれがそこにある必要がある理由を理解しようとしていますが、宣言の生成を中心にツールを構築していることを考えると、それを省略できるかどうかも理解しようとしています。

私は最初にそれがそこにある必要がある理由を理解しようとしていますが、宣言の生成を中心にツールを構築していることを考えると、それを省略できるかどうかも理解しようとしています。

プライベートが存在すると、分析ではクラスが名目上になるため、宣言ファイルでそれを保持することが重要です。 dts-downlevelような送信後の宣言トランスフォーマーツールを使用して、古いTSのプライベート宣言を何らかの方法でダウンレベル化することができますか？ （#privatesのダウンレベルがあるかどうかはまだわかりません）

Wesleyの発言に加えて、downlevel -dtsは、古いバージョンのTypeScriptとの互換性のために、 private privateを

プライベートが存在すると、分析ではクラスが名目上になるため、宣言ファイルでそれを保持することが重要です。

それがどのようにクラスを名目上にするかについて詳しく説明できますか？ 🙂複数のプライベートプロパティ#fooと#bar与えられた場合でも、宣言に追加される特別な#privateアンビエント宣言は1つだけです。 プライベートプロパティの名前も数も宣言から分析する方法はありません。これらはすべて単一の#privateプロパティ宣言に置き換えられているためです。 #fooと#barという名前を保持しておけば、もっとよく理解できます。 特に、LanguageServiceが#privateプロパティが使用されていないと文句を言うことを考えると、少し奇妙です。 それは私にはバグのように見えます。 しかし、すべての状況下で、プライベートフィールドはそのタイプのパブリックプロパティの一部ではなく、クラスの外部からアクセスできないため、理論的には、それらが宣言の一部である必要がある理由がわかりません。 KeyOfタイプではなく、アンビエント宣言の一部でもない、 public以外のアクセス修飾子でアノテーションが付けられたフィールドとメソッドに同じ原則を適用するべきではありませんか？

Wesleyの発言に加えて、downlevel -dtsは、古いバージョンのTypeScriptとの互換性のために、 private privateを

良い解決策のように聞こえます。 ただし、そうすることで、 private修飾子を指定するプロパティは、その型のパブリックプロパティの一部ではないため、 .d.tsファイルの一部にはなりません。 私は特に宣言に興味があります。宣言は、最も単純な例でも、 #privateと呼ばれる未使用のプロパティの診断を生成します。

@wessberg不要な言語サービスの警告に関して気付いたバグを

あなたの他の質問について：

それがどのようにクラスを名目上にするかについて詳しく説明できますか？

誰かが以前にそれについての問題を開い

これらの場合に何かを名目上のものにする理由の1つは、クラスの実装者がプライベートフィールド間で隠された不変条件を維持できるようにするためです。型を構造化すると、少なくとも「リストは常にソートされます」または「直径は2 *半径です」。

もう1つの理由は、実行時に「正しいことを行う」方法がないため、以下のようなコードは型チェックに失敗するはずであるということです。

class A {
    #foo = getFoo();
    bar = "bar";
    equals(other: A) {
        return this.#foo === other.#foo && this.bar === other.bar;
    }
}

new A().equals({ bar: "bar" }); // error: missing property '#foo'

やあ、やあ、 #private構文があるのはとてもうれしいです！ それは素晴らしいです！

しかし、私は本当に困惑していることを認めなければなりません。私たちは次のような速記構文を持っていません

class Counter {
  #count = 0
  increment() {
    return #count++
  }
}

私は疑問に思っていました—実験的な機能として短縮構文を有効にするtypescriptプラグインまたはtsconfigオプションを開発できますか？

不必要なthis.繰り返しを避けるために、人間工学に基づいた巧妙な改善を望んでいます。提案で指摘されているように、省略構文の欠点は、私が心配する重大な懸念ではないようです。だから私は確かに私自身のプロジェクトで"experimentalPrivateShorthand": trueまたはこのようなものを設定して幸せです

これはできますか？ 多分それが不可能な正当な理由がありますか？ 関係する作業は何でしょうか？ 乾杯！

：波：追跡

@ chase-moskal TypeScriptは、ECMAScript標準以外のTypes以外は何も実装していません。 この理由は、プライベートフィールドとデコレータによって示されるように、セマンティクスを変更することです。

@ chase-moskal this常に入力しないようにする最も実用的な方法は、正直なところ、IDEでショートカットを割り当てることです（たとえば、F3など）。 TSパーサーまたはBabelパーサーをフォークしてプラグインを作成することで多くのことが可能になりますが、それらはすべて多くの作業であり、公式のツールと同期しなくなります。 もちろん、あなたの質問は公式のサポートに関するものだったと思います。私の考えを共有したいと思いました。

@jhpratt —ヒップを維持するために使用されるtypescript。 それはあなたがたの昔に私にデコレータと矢印関数を与えてくれました！ 少なくとも今よりも、以前はbabelと競争力がありました

正直なところ、私は本当にゼリーベリーです。私のバベルのようなゴージャスなミニマルなクラスを書くことはできません。1年以上前に対応するものを使用することができました。バベルには、私がピン留めしているすべてのベルとホイッスルさえあります！

@mbrowne —読みやすさほど重要なのは、実際にはコードの「書き込み可能性」ではないので、キー押下のカウントについて心配する必要はありません。 私のポイントは、javascript this繰り返しは、余計な価値のない混乱であることが多すぎるということです。

読みやすさのためにこれを考えてみてください。省略形の#private構文を取得すると、 this表示されるたびに、パブリックメンバーに

とにかく、私はtypescriptがまだプライベートメソッドをサポートしていないことを発見しました

だから、これはすべて、明らかにブルームバーグの人々から、より多くの作業と時間を必要とします

フィールドに一致するプライベートメソッドがない場合は、待つ必要があります（狂気にならずに、同じクラスでtypescript-privatesとhashtag-privatesを混在させることはできないためです！）

それで、ここでタイプスクリプトを近代化するのはブルームバーグチームであり、彼らは1年前にもbabelの同じプライバシー機能に関与していましたか？ 彼らは神の仕事をしている、そして私はなぜ興味があるのか​​！ がんばり続ける！ 乾杯！

：波：追跡

はい、TypeScriptは何年も前にデコレータを提供しました。 何だと思う？ セマンティクスが変わった、大きな時間。 現在、TypeScriptは近い将来レガシーAPIのサポートに行き詰まっており、削除することを決定したときはいつでも大規模な破損を引き起こします。 矢印関数はECMAScript仕様の一部であるため、それを起動することはまったく関係ありません。

TypeScriptは現在、ステージ3に到達する前にECMAScriptプロポーザルを実装していません。TSが関心を持つ前に、ここで省略形を取得する必要があります。

はい、TypeScriptは何年も前にデコレータを提供しました。 何だと思う？ セマンティクスが変わった、大きな時間。

私たちは理想的な世界に住んでおらず、現在いくつかの機能が必要です。 たとえば、デコレータの提案はまだステージ2にありますが、一部の大きなプロジェクト（Angular）はそれらを長期間積極的に使用しています。 別の例：ECMAScriptは、クラスメンバーにprotected修飾子を指定していません。これは、実際の問題を解決するのに役立ちます。

現在、TypeScriptは近い将来レガシーAPIのサポートに行き詰まっており、削除することを決定したときはいつでも大規模な破損を引き起こします。

他の言語でも、コンパイラフラグの下に実験的な機能が導入されています。

TypeScriptがステージ1または2で各提案を実装する必要があるとは言いませんが、ECMAScriptには同等のものがないため、TSに関する多くの興味深い提案が行き詰まりました（例： https ：

@ikokostya TypeScriptがデコレータを実装した後にセマンティクスが変更された例として、デコレータを使用していました。 この速記は「今すぐ必要」だと本当に言っているのですか？ 私を信じてください、私たちは余分な5文字を管理することができます。 それがあなたにとってそれほど重要であるならば、あなたはコンパイラを自由にフォークすることができます。

TypeScriptは、フラグが立てられていても、ステージ3の前には何も実装しないことに固執しています。 これは、以前に他のさまざまな問題で徹底的に議論されました。

円を描く以外に何も見えないので、特筆すべきことが出てこない限り、これ以上対応しません。

@jhpratt私のポイントは速記ではありません。 私のコメントを読んでください。

フォークについての提案はまったく関係ありません。

誰もが同意するわけではありません。さらに言えば、TC39委員会の全員が同意するわけではありませんが、速記によってコードがより読みやすく、直感的になります。 これについては多くの議論があり、それらの懸念のために省略構文は別の提案に移されました。 （私自身の明確な意見を形成するのに十分なことを考えていませんでした。要約を与えるだけです。）この提案を前進させたい場合、先に進む方法はTC39にフィードバックを提供することです。 TSの維持と、ステージ3に到達したすべての提案の実装には、すでに多くの作業が含まれていると確信しています。したがって、TC39でさらに前進しない限り、これがTSで検討されることを想像するのは困難です。

しかし、私は速記構文を持っていないので本当に困惑していることを認めなければなりません

その省略形は、 #を使用する可能性のあるパイプライン提案と互換性がなく、ステージ2提案になることについてはすでに説明されています。 これほど早い段階で提案を実装してから、重大な変更を加えることは実際には意味がありません。 このような初期段階では、どの提案が勝つかさえわかりません。

互換性があることがわかったとしても、プレフィックス#演算子の使用例は、少なくともいくつか考えられます。これは、5文字余分に入力するための省略形よりも便利です。

…特に、プライベートフィールドのユースケースのかなりの部分がthisにまったくない場合（たとえば、 static isMe(obj) { try { obj.#x; return true; } catch { return false; } }など）。

@phaux —速記とパイプラインについての本当に良い情報です、ありがとう！

@jhpratt

TypeScriptは、フラグが立てられていても、ステージ3の前には何も実装しないことに固執しています。

十分に公平ですが、プライベートメソッドは実際にはステージ3ですが、タイプスクリプトのサポートはまだありません—見て、私は速記の提案がとても好きですが、それはただの美的です—私は実際には今はプライベートメソッドとアクセサーの欠如についてもっと悩まされています

ブルームバーグチームは、1年前のバベルの場合と同じように、ここでタイプスクリプトに関する神の仕事を続けていると思いますか？ もしそうなら、私たちは本当に辛抱強く座っている必要があります:)

typescriptは、ecmascript機能に関してbabelやブラウザとはるかに競争力があったように思えますが、実際には保守的すぎます。babelとchromeの両方が1年前にプライベートフィールド（フラグなし）を出荷していた状況にあります。ブルームバーグは私たちを救うためにやって来ました

私はtypescriptとbabelの機能セットの間の忍び寄る相違に不安を感じています—私のbabelの友達は昨年、美しく滑らかなコードを書いていますが、私はまだtypescriptのペナルティを払っています—彼らは私を笑っています！

私は、タイプスクリプトが実験的なフラグを提供していて、将来リファクタリングしていくつかの優れた機能を購入するリスクを判断できるのが好きでした。現在はタイプスクリプトの立場であり、開発者にそれらのリスクを決定させるのは危険すぎます。そのタイプスクリプトは今私の乳母ですか？

ますます、素晴らしい機能や静的なタイプを選択できるように見えますが、今では両方の長所を活かすことができないため、認知的不協和が高まっています。

ここでのダイナミクスに本当に興味があります。ブルームバーグが輝く鎧を着た騎士のように介入しなかったとしたら、typescriptが自分たちで挑戦するまでにどれくらいの時間がかかりましたか？ それとも、これはタイプスクリプトの実験ですか。「これらの新機能を回避するだけなら、コミュニティが私たちのためにそれを行うまでにどれくらいの時間がかかりますか？」、ハァッ、それは私にとってもかなり皮肉なことです！ それとも、これはオープンソースの資金調達とサポートのための新しい道を模索している本当にクールな慈悲深いコラボレーションであり、予想よりも少し遅いだけですか？ それとも、typescriptの哲学は、以前よりもはるかに保守的ですか？ このスペクトルのどこにいますか？

ステージ3の機能を実装する場合、typescriptに帯域幅や優先順位が不足しているということですか？

申し訳ありませんが、私はここで失礼なことや深刻な非難をするつもりはありません。部外者の視点から考えを投げかけるだけです。 私はただのユーザーであり、ここにいる人々が私が描いたこれらの写真にどのように反応するかについて本当に興味があります—興味深い議論、皆さんに感謝します！

：波：追跡

私は、タイプスクリプトが実験的なフラグを提供していて、将来リファクタリングしていくつかの優れた機能を購入するリスクを判断できるのが好きでした。現在はタイプスクリプトの立場であり、開発者にそれらのリスクを決定させるのは危険すぎます。そのタイプスクリプトは今私の乳母ですか？

それはあなたをうんざりさせることについてではありません。 それは、提案のセマンティクスが変更されたときに必然的にメンテナンスの負担になる機能の実装に時間を費やしたくないということです。 彼らは、TSの実装と競合しているときに、変更されたセマンティクスを調整する方法を理解することに時間を費やしたくありません。 彼らにはもっと良いことがあります。 解決すべき型関連の問題はまだ山ほどあるので、限られたリソースをそれに費やし、型システムの問題を解決することに加えてTC39の仕事をしようとしないのは理にかなっています。

プライベートメソッドとアクセサーについて：これらもV8では実装されていません。 クラスメソッドとインスタンスフィールドは異なり、それらをサポートするためにスイッチを切り替えることはできません。 それらを実装するには実際の時間がかかり、彼らはすでに現状のままで仕事でいっぱいであり、彼らは小さなチームです。 さらに、ルールは、プロポーザルがステージ3にある必要があるというだけではありません。また、プロポーザルのセマンティクスが最終的なものであることに高い信頼を置きたいと明確に述べています。 まれですが、セマンティクスはステージ3で変更できます。この機能は、正当な理由もなくV8に実装されていません。 誤解しないでください。 私もその提案が実行されるのを楽しみにしています、そしてそれを使うのが待ちきれません。 ただし、初期段階からの提案の実装は時間の無駄であり、TSチームの時間は他の場所でより適切に費やされます。 _今日_使用したいステージ2、1、0の提案は無数にありますが、まだそれらを使用できない理由は理解しています。 私の友人を我慢してください。

また、babelが提供するオプションを希望する場合は、babelを排他的に使用してタイプスクリプトをトランスパイルすることもできます。

@ 0kku —

@ljharb —これは非常に興味深いことです— typescriptとbabelをこのような方法で一緒に実行することは実際に可能ですか？ 両方の長所を達成するには？

しかし、私はvscode ts言語サービスが（たとえばプライベートメソッドのような）なじみのない構文を内破せずにどのように機能するのかを見ることができませんか？ インテリセンスの欠如は、typescriptの価値提案からあまりにも大きな塊を噛みます—インテリセンスを完全に無効にする必要がある場合、戦略は初心者ではありません

これを長期的にどのように修正できますか？ 実験的な機能の構文ごとに特定のタイプスクリプトエラーを区別し、タイプスクリプトプロジェクトがtsconfigレベルでそれらの特定のエラーを無効にできる場合は、babel機能とタイプスクリプト機能の両方を活用するためにドアを開けるショットがあると思います。同時に—本当にかっこいい男で、クラス全体の不満をノックアウトします。乾杯！

：波：追跡

@ljharb

また、タイプスクリプトをトランスパイルするために、babelを排他的に使用することもできます。

Babelを使用してプライベートメソッドのみをトランスパイルし（ただし、他のすべての型はそのままにして）、 tscを使用してそのコードの型チェックを実行する型チェックプロセスを設定できると思います。 （パスをタイプチェックした後のビルドスクリプトは、Babelのみを使用します。）しかし、IDEの多くの構文エラーを無視する必要があります。これは、ほとんどの人にとって大きな問題になると思います。

@ chase-moskal @ 0kkuが言ったことは一般的に正しいですが、見当たりません。 その提案はクラスフィールドよりも遅れてステージ3に到達しただけでなく、実装者はまだ取り組んでいると思います。

実験的な機能に飛びつくことに熱心でない理由に興味がある場合は、 --useDefineForClassFieldsある非常に複雑なclusterfoxtrotを参照してください。 異なるセマンティクスを持つ可能なTC39提案が存在する可能性すらあり得ないという仮定の下で、非常に早い段階でクラスプロパティ初期化子を実装しました。

デコレータは同じボートに乗る傾向にあり、古いセマンティクスのサポートを完全に廃止できると思うと、驚きます。 複数の大企業が、その周りによく採用されている大規模なフレームワークを構築しています。 「旗の名前はexperimental始まっていたので、過去5年間サポートされていたこの機能がいつかは消えてしまうかもしれないことを知っておくべきだった」と言えるのは完全に非現実的です。

これらの機能の両方について、私たちは残りの人生のためにここで2つの微妙に異なるコードパスを維持することに固執するでしょう、そしてそれはひどいです、しかしそれはトレードオフです-私たちはビルドツービルドのTypeScriptを維持することに非常にコミットしていますコードの実行時の動作を損なうことなく可能な更新。 このトレードオフは、それがあなたに有利な場合（たとえば、プログラムが機能し続ける場合）には見えませんが、熱心な機能の採用という点で欠点をより簡単に見ることができます。

私たちの観点からは、過失の責任を放棄できないのと同じように、バージョン間のランタイム互換性を放棄することはできません。

また、MASSIVEコミュニティの反発にもかかわらず、オプションのチェーンの早期採用を延期しました。誰かが「旗の後ろに置いてください」と言うたびにニッケルを持っていたら、ボートからこれを入力します。 しかし、それは正しいことでした。なぜなら、 (null)?.prop何を生成したかを推測する必要があり、 null （ undefinedではなく）を絶対に推測したからです。 dそれを理解するために、別の継続的な複雑さの負担を抱えて生きている。 強い反事実は誰で満たさ300万行のコードベースにこだわって座っていないという事実のために逆さまここにあります?. 、彼らが生産することに依存する用法nullにない方法で、時々別のundefined動作に移行する方法を理解することさえできます。

ブルームバーグは、この機能を利用することに非常に興奮し、TypeScriptに貢献することを熱望していたため、プライベートフィールドを実装しました。 もし彼らがこのような状況になかったら、他のすべてと同じように、私たちは自分たちでこの機能を実装していたでしょう。

一般に、JavaScriptのタイムラインは非常に長く、現実的には、2020年の構文を使用せずに2016年に優れた人間工学的JSを作成できるのと同じように、2024年の構文を使用せずに2020年に優れた人間工学的JavaScriptを作成できます。 最終的に決定されたセマンティクスすら持っていない構文を使用できないことによって、だれもブロックされません。 その時点では、それは単なる架空のプログラミングです。

それだけでなく、現在のクラスフィールドの提案とそのすべての詳細が現在の形式でステージ4に到達するかどうかも100％確実ではありません（特に、提案を完全に破棄して置き換えることを扇動しているTC39メンバー企業があります）別のもので）。 95％の確実性があると思いますが、一般的に、ステージ3の提案を実装することでさえ完全にリスクがないわけではありません。 ただし、ステージ3以降にさらに変更される可能性は非常に低いため、現在のTSポリシーは適切だと思います。

[クラスフィールド]の提案を完全に破棄して別の提案に置き換えることを扇動しているTC39メンバー企業があります。

興味深いことに、マインドポイントはそれにリンクしていますか？

アイデアは次のとおりです。おそらく、TSチームはプラグインシステムを改善するために時間を費やして、プラグインの作成者にコンパイル時と言語サーバープロトコルのインテリセンス時間の両方にフックする明確なAPIを提供することができます。 これにより、サードパーティが新しい構文を含む実験的な機能を実装し、IDEやテキストエディタ内でインテリセンスを機能させることが可能になります。

最後に確認したところ、 ttypescriptはtsconfig.jsonで非プログラム的にTypeScriptトランスフォーマーを構成する唯一の方法であり、IDEのインテリセンスにフックしないため、サードパーティがVSCodeのような既存のツールはまだありません。 ttypescript切り替えて、VS Codeが構文を理解できず、エラーをスローしている間は端末出力に依存する必要があるため、VSCodeの優れたエクスペリエンスを放棄したくありません。

次に、TypeScriptは安定した機能に焦点を合わせ、サードパーティに危険な実験的機能を作成または使用させることができます（Babelエコシステムと同じくらい簡単です）。

興味深いことに、マインドポイントはそれにリンクしていますか？

https://github.com/microsoft/TypeScript/pull/30829#issuecomment -541338266

Babelプラグインで実行できる構文上のことは非常に限られています。 基本的に、パーサーはすでにそれをサポートしている必要があります。 たとえば、 do式の「プラグイン」には、Babel自体のコアにロジックが必要です。https ：

プライベートクラスのメソッドとアクセサーについて従うことができる問題はありますか？

@RyanCavanaugh

これらの機能の両方について、私たちは残りの人生の間、ここで2つの微妙に異なるコードパスを維持することに固執するでしょう

私はそれがこのように進むべきではないと思います、そしてそれがコミュニティ全体を傷つけることを想像することができます。 デコレータがステージ3に達した場合、新しいバージョンのデコレータにアップグレードするための時間を提供することは合理的だと思います。 しばらくの間は両方をサポートする可能性があり、ハードスイッチを作成してTypeScript4 +でレガシーデコレータを削除する可能性があります。 古いデコレータと新しいデコレータの違いは使用しないのでわかりません（まあ、実験的な機能です）。 しかし、提案が彼らのニーズを満たさない場合、影響を受けるプロジェクトは提案に取り組むべきだと思います。 それは誰にとっても良いことです。 TypeScriptは、レガシー機能と実験的機能についての戦争を巻き起こすには間違った場所です。

ここに着陸したことを後悔しています：/

@RyanCavanaugh

Babelプラグインで実行できる構文上のことは非常に限られています。 基本的に、パーサーはすでにそれをサポートしている必要があります。

NS。 ただし、TypeScriptと比較するために、Babelでは、パーサーだけをフォークして、カスタムパーサーと作成したカスタム構文プラグインを使用するようにbabel.config.jsを設定できます。 はい、それは多くの作業です（特に、新しい構文を初めて追加する方法を学ぶ）が、TSの同等のオプションを認識していません。もちろん、Babelでは、既存の構文に基づいて変換プラグインを作成する方がはるかに簡単です。 TypeScriptのカスタマイズオプションの現在の状態はわかりませんが、数年前に最後に調べたとき、すべてをフォークする以外に拡張するオプションはないようでした。

これを試してください： https ：

プライベートIMOのハッシュは醜くて紛らわしいです。 それ以外の方法でそれらを実装する方法がないため、それは難しい強制です。 TSのようなビルドステップはありません。 その結果、コードがシンボルで詰まってしまい、「ハードプライベート」がほとんど得られず、デフォルトではプライベートにする必要があると多くの人が教えられているため、JSを書く「正しい」方法だと考えています。
特に問題について明らかな意見の不一致があった場合は、それを標準にプッシュする前に、より多くの提案があったはずです。

@ robot56は、デフォルトでは非公開にする教えられていますが、実際には誰にとっても良いことではありません。

@ljharbはい、そうすべきです。 ただし、プライベートを宣言する方法が変数の前にハッシュシンボルをスローするようになった場合、JSでクラスを作成する「正しい」方法は、メンバー変数の前にハッシュを配置するように人々に教えることを意味します。 それらを宣言するときだけでなく、それらを参照するときも。 あなたが他の言語から来ているなら、それは特に混乱します。 this.#x = this.#something();ようなものとクラスでの宣言を見たときの私の最初の考えは、ハッシュが変数自体の一部であるということでした。 私はそれが修飾子だとは思いもしませんでした。 パブリックのアンダースコア、それも逆に思えます。 これはTSにはあまり関係ありませんが、私が推測する厄介な怒りです。

はい、親しみやすさに固執したときに新しいことを学ぶことは調整かもしれません。 JSコミュニティはこれからも学び続けると信じています！

（ハッシュは変数自体の一部であり、 this.#xの名前は「xではなくプライベート」ですが、実際には、その字句スコープ内の一意の値である#x ）

はい、親しみやすさに固執したときに新しいことを学ぶことは調整かもしれません。 JSコミュニティはこれからも学び続けると信じています！

あなたの言い方では、それが私たちのプログラミングの知恵に追加する何かを学んでいたように聞こえますが、これはJSのもう1つの癖であり、覚えておく必要があります：D