原文：青色表示
訳文：黒色表示
注記/訂正： 赤色表示
Ok, so that's how class constructor functions and their prototype properties are set up, what about the actual prototype chain of a XPConnected DOM object? The beauty of this code is that the prototype property of a class constructor is the real XPConnect prototype for that class. When XPConnect wraps a DOM object (i.e. creates a XPConnect JS wrapper for a DOM object), XPConnect will call the scriptable helper method nsDOMClassInfo::PostCreate() which will make sure the prototype chain of the wrapper JSObject is properly set up. In this call, the nsDOMClassInfo code just needs to resolve the name of the class on the global object, and the prototype will be set up by the resolving code (nsWindowSH::GlobalResolve()). This is also done only once per class, nsDOMClassInfo::PostCreate() checks if the prototype of the prototype of the wrapper JSObject (i.e. obj.__proto__.__proto__) has been set up already, if it has, then there's nothing left to do in nsDOMClassInfo::PostCreate().
いいですね。さてこんな風にしてクラスコンストラクタ関数やそのプロトタイププロパティが設定されますが、XPConnect を使った DOM オブジェクトの実際のプロトタイプの連鎖についてはどうでしょうか。クラスコンストラクタのプロトタイププロパティがそのクラスの実際の XPConnect のプロトタイプであるというのがこのコードの美しさです。XPConnect が DOM オブジェクトをラップする (例えば DOM オブジェクトに対して、XPConnect の JS ラッパを生成する)時、XPConnect はスクリプト可能な支援メソッドである nsDOMClassInfo::PostCreate() を呼び出し、これによって、ラッパである JSObject のプロトタイプの連鎖が正しく設定されることが確実になります。この呼び出しで、nsDOMClassInfo コードはグローバルオブジェクトのクラス名を解析するだけでよく、解析コード (nsWindowSH::GlobalResolve()) によってプロトタイプが設定されます。これもクラス単位に一度だけ解析され、 nsDOMClassInfo::PostCreate() はラッパである JSObject (例 obj.__proto__.__proto__) がすでに設定されているかを確認し、もし設定済であれば、nsDOMClassInfo::PostCreate() がすることは何もありません。
これで、この文書の草稿が完成しました。早速 Mozilla org. のフォーラムで公開し、Community の方々のご意見を仰ぐことになります。ダメだしも含め、出来るだけ多くのご指摘をいただければと思います。
