Type Scriptの私有属性
8188 ワード
私たちはType Scriptは直接ブラウザで実行できないし、nodejsで直接実行できないことを知っています.これらの環境ではjsにコンパイルしてから実行できます.
もちろんこれは絶対ではありません.去年はnodejsの父が新たに穴を開けました.Denoは直接Type Scriptを実行できます.
Type Scriptは最終的にjsにコンパイルされてブラウザやnodejs環境で実行されると思っていましたが、Type Scriptの中の全ての特性は、jsの中で対応する書き方を見つけることができますか?
以前はType Scriptの中のタイプの実現を見ていましたが、とても面白いと思います.特にType Scriptのソースコードとコンパイル後のjsコードを比較しています.
例えばtypeScriptの列挙:
また、このコンパイルからjsコードを取得すると、オブジェクトの属性に対して価値を付与するという興味深いテクニックを学びました.
しかし、対象のget\set属性を結び付けて考えてみると、この道理は分かりやすくないと思います.
賦値は、同じ方法で呼び出されたもので、最後に戻り値を返します.この戻り値はちょうど入ってきた値です.
この概念が長く使われているとき、当然のことながら、Type Scriptのコードはすべて対応するJavaScriptコードにコンパイルされているはずで、論理にも合致しているはずです.
しかし、私はクラスの私有属性に出会って、やっと私の慣性認識を覆しました.
私たちが知っているのは、Javascriptのクラスには私有属性がありません.プライベート属性をシミュレートするなら、クローズドでシミュレーションしなければなりません.
例えば、以下のType Scriptコード
しかし、実際には最新のType Script 3.1バージョンで上記のコードをコンパイルした後、結果はこうなりました.
この問題は長い間悩んでいましたが、なかなか解けません.
デノを見て、その理由を知りたいです.
Type ScriptはJavaScriptのオーバーセットであることを知っています.Type Scriptの中の概念は必ずしもJavaScriptの中に存在するとは限りませんが、逆に肯定的です.
この点が分かれば、そのわけは分かります.
Type ScriptはJavaScriptのいくつかの痛みを解決しました.タイプの制約がなく、ブラウザのサポートが遅れています.しかしこれは、Type ScriptはJavaScriptに等しいという意味ではない.もし両者が完全に同じなら、こんなに強力な力を使って新しい輪を作る必要があるだろうか?
Type ScriptはJavaScriptにコンパイルされた後のコードです.他のJavaScriptのソースコードを混ぜて使うなら、やはり安全性の保証が足りません.しかし、その安全性はType Scriptで私たちのプロジェクトを書いています.コンパイラはType Scriptのソースコードをコンパイルして成能で正確に実行するJavaScriptコードを担当します.そして少なくとも99.99%の確率で運行中に間違いがないことを確認できます.
マシンコードと高級プログラミング言語の関係を連想させます.すべてのプログラミング言語がマシンコードにコンパイルされてコンピュータに走れるというのに、なぜJavaScriptが書いたコードの安全性が悪いというのですか?Javaが書いたコードの安全性がもっと良くて、もっと大きなプロジェクトに適していますか?
なぜなら、言語によってユーザーに対する要求が異なるからでしょう.JavaScriptのベテランをよく知っています.書いたコードはJavaより新しく手書きしたコードの信頼性が悪いとは信じられません.
JavaScriptをナイフにたとえたら、Javaはナイフです.
刀を切るのは威風堂々としていて、作戦半径が大きいので、力の強い人でさえあれば、持ってきて勇敢に戦場に行って人を切ります.しかし、ナイフは、多くの人が持っています.これは短いです.人を斬るのは人に送るものではないですか?
刀を切るのは使いやすいですが、上手に使うのは難しいです.有効に敵を殺すのはもっと難しいです.短剣は難しいが、習えば近戦で肉薄し、殺人の効率は恐ろしい.
もちろんこれは絶対ではありません.去年はnodejsの父が新たに穴を開けました.Denoは直接Type Scriptを実行できます.
Type Scriptは最終的にjsにコンパイルされてブラウザやnodejs環境で実行されると思っていましたが、Type Scriptの中の全ての特性は、jsの中で対応する書き方を見つけることができますか?
以前はType Scriptの中のタイプの実現を見ていましたが、とても面白いと思います.特にType Scriptのソースコードとコンパイル後のjsコードを比較しています.
例えばtypeScriptの列挙:
enum Color {
Red = 1,
Green,
Blue
}
let c: Color = Color.Green;
コンパイル後のjsコード:var Color;
(function (Color) {
Color[Color["Red"] = 1] = "Red";
Color[Color["Green"] = 2] = "Green";
Color[Color["Blue"] = 3] = "Blue";
})(Color || (Color = {}));
var c = Color.Green;
例えば今まで思ったことがありませんでした.jsはこのように遊んで、対象を作って、対象の中のkey、valueは互いに写像することができます.keyを通じてvalueを見つけられます.valueを通じてkeyも見つけられます.もちろん、この中で、key、valueを一つのデータの代名詞として理解しなければなりません.例では色と数値が必要です.また、このコンパイルからjsコードを取得すると、オブジェクトの属性に対して価値を付与するという興味深いテクニックを学びました.
しかし、対象のget\set属性を結び付けて考えてみると、この道理は分かりやすくないと思います.
賦値は、同じ方法で呼び出されたもので、最後に戻り値を返します.この戻り値はちょうど入ってきた値です.
この概念が長く使われているとき、当然のことながら、Type Scriptのコードはすべて対応するJavaScriptコードにコンパイルされているはずで、論理にも合致しているはずです.
しかし、私はクラスの私有属性に出会って、やっと私の慣性認識を覆しました.
私たちが知っているのは、Javascriptのクラスには私有属性がありません.プライベート属性をシミュレートするなら、クローズドでシミュレーションしなければなりません.
例えば、以下のType Scriptコード
class Animal {
private name: string;
constructor(theName: string) {
this.name = theName;
}
private sayName(): string {
return this.name;
}
}
JavaScriptにコンパイルすると思っていましたが、var Animal = /** @class */ (function () {
var name;
function Animal(theName) {
name = theName;
}
Animal.prototype.sayName = function () {
return name;
};
return Animal;
}());
コンパイルした後、コードが私の予想したようになると、この場所の私有属性も合理的です.結局、私はこのタイプの外部ではこの属性に全くアクセスできません.このタイプの作用領域を定義するだけで、内部にアクセスできます.しかし、実際には最新のType Script 3.1バージョンで上記のコードをコンパイルした後、結果はこうなりました.
var Animal = /** @class */ (function () {
function Animal(theName) {
this.name = theName;
}
Animal.prototype.sayName = function () {
return this.name;
};
return Animal;
}());
この結果は最初は分かりにくいです.このように構造関数を定義すると、このnameはどうやって私有属性を計算できますか?この問題は長い間悩んでいましたが、なかなか解けません.
デノを見て、その理由を知りたいです.
Type ScriptはJavaScriptのオーバーセットであることを知っています.Type Scriptの中の概念は必ずしもJavaScriptの中に存在するとは限りませんが、逆に肯定的です.
この点が分かれば、そのわけは分かります.
Type ScriptはJavaScriptのいくつかの痛みを解決しました.タイプの制約がなく、ブラウザのサポートが遅れています.しかしこれは、Type ScriptはJavaScriptに等しいという意味ではない.もし両者が完全に同じなら、こんなに強力な力を使って新しい輪を作る必要があるだろうか?
Type ScriptはJavaScriptにコンパイルされた後のコードです.他のJavaScriptのソースコードを混ぜて使うなら、やはり安全性の保証が足りません.しかし、その安全性はType Scriptで私たちのプロジェクトを書いています.コンパイラはType Scriptのソースコードをコンパイルして成能で正確に実行するJavaScriptコードを担当します.そして少なくとも99.99%の確率で運行中に間違いがないことを確認できます.
マシンコードと高級プログラミング言語の関係を連想させます.すべてのプログラミング言語がマシンコードにコンパイルされてコンピュータに走れるというのに、なぜJavaScriptが書いたコードの安全性が悪いというのですか?Javaが書いたコードの安全性がもっと良くて、もっと大きなプロジェクトに適していますか?
なぜなら、言語によってユーザーに対する要求が異なるからでしょう.JavaScriptのベテランをよく知っています.書いたコードはJavaより新しく手書きしたコードの信頼性が悪いとは信じられません.
JavaScriptをナイフにたとえたら、Javaはナイフです.
刀を切るのは威風堂々としていて、作戦半径が大きいので、力の強い人でさえあれば、持ってきて勇敢に戦場に行って人を切ります.しかし、ナイフは、多くの人が持っています.これは短いです.人を斬るのは人に送るものではないですか?
刀を切るのは使いやすいですが、上手に使うのは難しいです.有効に敵を殺すのはもっと難しいです.短剣は難しいが、習えば近戦で肉薄し、殺人の効率は恐ろしい.