ECMAScript 仕様では、「制御が実行コンテキストに入る前に作成される一意のグローバル オブジェクト」が定義されています。このグローバル オブジェクトは、ECMAScript の標準組み込みオブジェクトであり、ネイティブ オブジェクトです。
仕様には次のようにも記載されています。
この仕様で定義されたプロパティに加えて、グローバル オブジェクトには追加のホスト定義プロパティがある場合があります。これには、値がグローバル オブジェクト自体であるプロパティが含まれる場合があります。たとえば、HTML ドキュメント オブジェクト モデルでは、グローバル オブジェクトの
windowプロパティはグローバル オブジェクトそのものです。
そのため、Web ブラウザでは、windowオブジェクトは ECMAScript グローバル オブジェクトの便利な名前にすぎないため、windowオブジェクトはネイティブの ECMAScript オブジェクトです。
これを正しく取得しましたか？
これは主に、「ネイティブオブジェクト」または「ホストオブジェクト」であることが実際に何を意味するのかという問題に帰着します。ECMAScript仕様は、これらの用語のかなり抽象的な定義を提供し、定義の異なる解釈のための十分な余地があります。たとえば、ネイティブオブジェクトの定義では、「セマンティクス」という言葉が実際に話しているのは何ですか。これは、（[[propName]]内部プロパティで指定されたESの）プリミティブオブジェクトセマンティクスだけですか、それともオブジェクトのアプリケーションレベルのセマンティクスを含みますか。DOMウィンドウオブジェクトには、ES仕様で定義されていない、観察可能なアプリケーションレベルのセマンティクスがあるため、これらのセマンティクスを考慮した場合、「ネイティブオブジェクト」にすることはできません。
実装の語用論の問題として見れば、答えはおそらくはるかに簡単です。ESエンジンの実装者は、ESヒープに割り当てられ、ESガベージコレクターによって管理されるオブジェクトを「ネイティブESオブジェクト」と見なす可能性があります。「ホストオブジェクト」は通常、ESヒープの外部に存在し、COM、XPCOM、V8埋め込みAPIなどのある種の相互運用性レイヤーを使用してアクセスされるものと考えられます。実装によっては、DOMウィンドウオブジェクトがいずれかのカテゴリに分類される場合があります。この区別は、仕様レベルの区別よりも、エンジン実装者とホストプロバイダーの両方におそらく関連性があります。
ES仕様の次の版では、さらに定義が明確になる可能性があります。「ネイティブ」および「ホスト」オブジェクトの用語を削除する提案もあります：http ：//wiki.ecmascript.org/doku.php？id = strawman：terminology 。ただし、そのような定義が実際に非常に実用的な影響を与えるかどうかは明らかではありません。
私は、仕様がグローバル オブジェクトがネイティブ オブジェクトであることを要求していないと主張することができます (おそらくそうするでしょう)。この仕様では、ネイティブ オブジェクトを次のように定義しています。
ホスト環境ではなく、この仕様によってセマンティクスが完全に定義されている ECMAScript 実装のオブジェクト。
そして、ホスト オブジェクトの定義:
ECMAScript の実行環境を完成させるために、ホスト環境によって提供されるオブジェクト。
ホスト オブジェクトの定義は、確かに に適用できますwindow。これは、ECMAScript の実行環境を完成させるためにホスト環境によって提供されるオブジェクトです。さらに、そのセマンティクスは ECMAScript 仕様によって完全には定義されていません。
また、V8 や TraceMonkey などのブラウザーで実行される ECMAScript エンジンがwindowオブジェクトを作成しない場合もあります。むしろ、DOM によって提供されます (たとえば、DOMWindowまたはから構築および継承されます)。Window
はい、あなたの推論は正しいように聞こえます。半証明として、関数が明示的にthis(「グローバル コンテキストで」) 実行されない場合、その関数は関数本体内でthis評価されます。windowしかし、これは実際には JSVM 固有のものです。たとえば、この v8-users メッセージ(および関連する議論) を見てください。物事は舞台裏でもう少し複雑ですが、ユーザーに説明するのとほぼ同じように見えます。