JavaScript-DOM Prototypes in Mozilla 草稿化 9

原文：青色表示
訳文：黒色表示
注記/訂正： 赤色表示

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 の方々のご意見を仰ぐことになります。ダメだしも含め、出来るだけ多くのご指摘をいただければと思います。

JavaScript-DOM Prototypes in Mozilla 草稿化 8

昨日フォーラムで長く草稿公開の状態にあったGecko Info for Windows Accessibility Vendorsの和訳草稿をようやく完成稿にした。原文も頻繁に見直されており、改訂変更が著しいこともあってしばらく放置状態にあった。しかし、そのような変更も出尽くした感があり、その後　Mozilla community の方々の草稿に対する新たな指摘もないので、最終的見直しをして完成稿とした。原著者の Aaron さんにその旨を報告すると以下のような返信があった。

Thank you!

Would you be so kind as to help find Japanese assistive technology vendors and notify them about your document?

I will keep this URL safe so I can send it if I get any requests, but I do not have connections in Japan.

- Aaron

Aaron Leventhal
IBM web accessibility architect

ようするに、日本のアクセシビリティ関連のベンダーに上記の文書を紹介して欲しいという依頼である。この件は、以前草稿作成中に原文について何かの照会を入れた際にも同様の依頼をうけていた。そこで、その時は Mozilla Japan org. の和訳部門経由で Mozilla Japan へ Aaron さんのご希望を伝えた。さらに、自分としては Aaron さんの紹介をする小さなサイトを作った。その時、日本IBM がアクセシビリティ関連の vendor でもあることを知ったので、今回その件を Aaron さんに伝えた。というのは、現在 Aaron さんご自身も本家の IMB で働いておられるからである。すると、日本IMBへコンタクトしてみるという返事があった。
----------------------------------------------------------------------------

原文：青色表示
訳文：黒色表示
注記/訂正： 赤色表示

As the prototype property of the constructor function is being defined, the code also sets up the prototype of the prototype property of the constructor function (i.e. HTMLImageElement.prototype.__proto__). To do this, the code figures out what the name of the immediate prototype of the class is by looking at the parent of the primary interface in the class info (if the name is a class constructor, such as HTMLImageElement) or by looking at the parent of the interface that the IID stored in the nsScriptNameSpaceManager for this name represents (if the name is a class prototype, such as Node). Once the name of the parent interface is known (and the name is not nsISupports) the code will look up a property by that name on the global object. This will cause the code to recurse down along the parent chain of the interface of interest for the name we started out resolving (i.e. nsWindowSH::GlobalResolve() will be called for every name on the parent chain). The result of this recursion is that by resolving the name HTMLImageElement, we'll create the constructor functions HTMLImageElement, HTMLElement, Element, and Node, and the prototype properties on all those constructor functions will be correctly set up. This means that the next time the name of a class constructor is resolved in the same scope, say HTMLAnchorElement, the code will resolve the name HTMLAnchorElement, find the parent name, which is HTMLElement, and resolve that, but since we've already resolved HTMLElement as a result of resolving the name HTMLImageElement earlier, the recursion will stop right there.

コンストラクタ関数のプロトタイププロパティが定義されている中で、コードはコンストラクタ関数のプロトタイププロパティのプロトタイプ(例 HTMLImageElement.prototype.__proto__) も設定します。そのために、コードは class info の主要なインターフェイスの親を調べることで (HTMLImageElement などクラスコンストラクタの名前であれば)、クラスの直接のプロトタイプ名がなんであるかが分かります。あるいは、この名前に対して nsScriptNameSpaceManager クラスに保持された IID 【訳注:一意なインタフェース識別子】 が表す（名前が Node などクラスプロトタイプの名前であれば）インターフェイスの親を調べることで分かります。一度親インターフェイス名が分かると（それが nsISupports でなければ）コードはグローバルオブジェクトの親インターフェイス名によってプロパティを調べます。こうすることで、コードは関連するインターフェイスの親の連鎖にそって、解析を始めていた名前を求めて再帰呼び出しをします(例えば、nsWindowSH::GlobalResolve() が親の連鎖にある名前毎に呼び出されます)。再帰呼び出しの結果、HTMLImageElement 名を解析することで、コンストラクタ関数である HTMLImageElement、HTMLElement、Element、Node が生成され、これらのコンストラクタ関数のすべてのプロトタイプのプロパティが正しく設定されます。つまり、次回は同じ領域でクラスコンストラクタの名前が解析されることになります。例えば HTMLAnchorElement では、HTMLAnchorElement 名を解析し、HTMLElement であると親の名を見つけ、さらにそれを解析しますが、以前に HTMLImageElement 名を解析した結果 HTMLElement はすでに解析済なので、ここで再帰呼び出しは停止します。

JavaScript-DOM Prototypes in Mozilla 草稿化 7

原文：青色表示
訳文：黒色表示
注記/訂正： 赤色表示

Once the registration is done, the nsDOMClassInfo code uses the registry every time a named property is resolved on a global object (because of this the nsScriptNameSpaceManager needs to be pretty fast at looking things up in its registry, that's why it's a hash table). When a property is resolved on the global object, the nsDOMClassInfo code will ask the nsScriptNameSpaceManager if the name is a known name (in nsWindowSH::GlobalResolve()), if the name is known, the code will look at the type of the name and act accordingly.
一度登録されると、nsDOMClassInfo コードは、名前の付いたプロパティがグローバルオブジェクトで解析される度に（このために nsScriptNameSpaceManager はプロパティの登録内容の検索を素早くする必要があるので、ハッシュテーブルを使っています）、登録を利用します。グローバルオブジェクトでプロパティが解析されると、nsDOMClassInfo コードは nsScriptNameSpaceManager に (nsWindowSH::GlobalResolve()で) プロパティ名が既知のものかどうかを確認し、そうであれば、コードは名前の型を調べそれに応じて動作します。

If a class constructor or class prototype name is resolved, the class info code will define the constructor function for that class, and also define the prototype property of that constructor function (i.e. HTMLImageElement.prototype). The prototype of a constructor function will either be the prototype object that XPConnect creates for a class (if the name is the name of a real class) or simply an empty JSObject of a specific JSClass that is defined in nsDOMClassInfo.cpp (nsDOMClassInfo::sDOMConstructorProtoClass).
クラスコンストラクタやクラスプロトタイプ名が解析されると、class info のコードはそのクラスのコンストラクタ関数を定義し、そのコンストラクタ関数のプロトタイプのプロパティも定義します (例えば TMLImageElement.prototype)。コンストラクタ関数のプロパティは (名前が実クラスの名前であれば) クラス用に XPConnect が生成するプロトタイプオブジェクトか、あるいは単に nsDOMClassInfo.cpp (nsDOMClassInfo::sDOMConstructorProtoClass) で定義されている特定の JSClass　の空の JSObject であるかのいずれかです。

JavaScript-DOM Prototypes in Mozilla 草稿化 6

原文：青色表示
訳文：黒色表示
注記/訂正： 赤色表示

So how does all this work in the mozilla DOM code?

It all happens in XPConnect and nsDOMClassInfo.{cpp,h} in the DOM code. During startup, the nsDOMClassInfo code registers two different types of "global names", these are names of properties of the global object with special meaning to the DOM code. The two types of "global names" are, class constructor names and class prototype names. What's the difference? Class constructor names are names of real classes, and class prototype names are names of "classes" that are inherited by real classes, but are not real classes. A few examples of class constructor names would be HTMLImageElement, HTMLDocument, Element, NodeList, and a few examples of class prototype names would be Node, CharacterData. This registration is done with the nsScriptNameSpaceManager, which is in charge of keeping track of what names are registerd in the global namespace, and what kinds of names those names are (i.e. class constructor name, class prototype name). When a class constructor name is registerd (nsGlobalNameStruct::eTypeClassConstructor), the nsScriptNameSpaceManager is given a DOM class info ID, this is a 32 bit ID that identifies class info defined in nsDOMClassInfo. When a class prototype name is registered (nsGlobalNameStruct::eTypeClassProto), the nsScriptNameSpaceManager is given the nsIID of the interface that's inherited by the class of which the registerd name is a prototype (i.e. NS_GET_IID(nsIDOMNode) for Node). nsScriptNameSpaceManager also deals with other types of names, but those are unrelated to the DOM object prototype setup, so we'll ignore those here.


それでは、これらはすべて Mozilla の DOM コードでどう機能するのでしょう?

XPConnect や DOM コードの nsDOMClassInfo.{cpp,h} で上記はいつも発生します。起動中に nsDOMClassInfo コードは 2 つの異なる型の”グローバルな名前”を登録しますが、これらは DOM コードに対し特別な意味を備えたグローバルオブジェクトのプロパティの名前です。2 つの型の”グローバルな名前”とは、クラスコンストラクタの名前とクラスプロトタイプの名前です。その違いは何でしょうか？クラスコンストラクタの名前は実クラスの名前ですが、クラスプロトタイプの名前は実クラスによって継承される実クラスではない”クラス”の名前です。いくつかのクラスコンストラクタの名前を挙げると HTMLImageElement、HTMLDocument、Element、NodeList となり、またクラスプロトタイプの名前は Node、CharacterData となります。登録は nsScriptNameSpaceManager によってされ、その役割はグローバルな名前スペースに登録された名前とその名前の型(例えばクラスコンストラクタ名やクラスプロトタイプ名)を記録することです。クラスコンストラクタの名前 (nsGlobalNameStruct::eTypeClassConstructor) が登録される時、nsScriptNameSpaceManager は DOM class info ID を受け取りますが、これは nsDOMClassInfo で定義された class info を識別する 32 ビットの ID です。クラスプロトタイプの名前(nsGlobalNameStruct::eTypeClassProto) が登録される時、nsScriptNameSpaceManager はインターフェイスの nsIID を受け取りますが、このインターフェイスは、登録されたクラス名がプロトタイプであるクラスによって継承されます(例えば Node 用の NS_GET_IID(nsIDOMNode))。nsScriptNameSpaceManager は他の名前の型も処理しますが、それらは DOM オブジェクトのプロトタイプの設定には関係ありませんので、ここでは考慮しません。

JavaScript-DOM Prototypes in Mozilla 草稿化 5

原文：青色表示
訳文：黒色表示
注記/訂正： 赤色表示

So far so good, we have shared prototypes, and XPConnect gives us most of this automatically (except the constructor functions on the global object). But this is not good enough, in addition to being able to share and represent each "class" with a constructor function, we also want users to be able to extend "classes" that are not real concrete classes, like Node for instance. Node is a DOM interface, but there is no Node class, there are lots of different classes that "inherit" Node (HTMLImageElement, HTMLDocument, ProcessingInstruction, ...), but an instance of Node will never exist in mozilla. But the fact that an instance of a Node will never exist in mozilla doesn't mean that the Node class is useless, the Node class is indeed very useful since it gives the user even more flexibility when working with the mozilla DOM. If you think back to the HTMLImageElement samples above, those samples let you define new properties on all image elements, by using the Node constructor function you can do similar things to *all* objects that "inherit" Node. This means you can add a property to every node in a DOM tree by doing something like this:
Node.prototype.foo = bar;

今までのところは順調です。共用のプロトタイプがあり、（グローバルオブジェクトのコンストラクタ関数を除けば）XPConnect は自動的に共用のプロトタイプのほどんどを提供します。しかし、これだけでは十分とは言えません。コンストラクタ関数で”各々の”クラスを共用し代用させることが可能であるばかりでなく、インスタンスへの Node のような本当の具象クラスでない”クラス”をユーザが拡張できるようになることが必要だと思います。Node は DOM のインターフェイスですが、Node クラスは存在しません。Node を”継承”する様々なクラスはたくさんありますが (HTMLImageElement、HTMLDocument、ProcessingInstruction、 ...)、Mozilla には Node のインスタンスはありません。しかし、Mozilla には Node がないという事実は Node クラスが役に立たないということではありません。実のところ Node クラスは、それが Mozilla DOM と一緒に機能すればユーザにより多くの柔軟性を提供するので、大変役に立つのです。上記の HTMLImageElement のサンプルに戻って考えると、これらのサンプルで、Node を”継承”する *all* オブジェクトへ似たようなことができる Node コンストラクタ関数を使うことで、すべてのイメージ要素で新しいプロパティを定義することが可能になります。つまり以下のようにすれば、DOM ツリーのすべてのノードへ新しいプロパティを追加できるのです:
Node.prototype.foo = bar;

Here's a little diagram that shows the prototype layout of a HTMLDivElement in mozilla.
Mozilla における HTMLDivElement のプロトタイプのレイアウトを示す簡単なフローです。
HTMLDivElement.prototype
|
|.__proto__
|
HTMLElement.prototype
|
|.__proto__
|
Element.prototype
|
|.__proto__
|
Node.prototype
|
|.__proto__
|
Object.prototype
|
|.__proto__
|
null

If you have an instance of a HTMLDivElement in JS, the following will be true:
div.__proto__ === HTMLDivElement.prototype

JS で HTMLDivElement のインスタンスがあれば、以下の条件は真となります:
div.__proto__ === HTMLDivElement.prototype

and the following should also be true, but it's not yet so in mozilla:
div.constructor === HTMLDivElement

以下も真となるはずですが、 Mozilla ではまだそうなっていません:
div.constructor === HTMLDivElement

which means that the following should also be true:
div.__proto__ === div.constructor.prototype

ということは、以下もまた真になるはずです:
div.__proto__ === div.constructor.prototype

JavaScript-DOM Prototypes in Mozilla 草稿化 4

原文：青色表示
訳文：黒色表示
注記/訂正： 赤色表示

This would make every image in this document have a callable foo property (i.e. a foo() method).
このコードを使ったドキュメント中のすべてのイメージは呼び出し可能な foo プロパティ (例 foo() method) を備えます。

Alternatively, and this is actually the standard way of doing this (see the ECMAScript specification), one can access and modify the prototype of an HTMLImageElement through the prototype property of the constructor function:
HTMLImageElement.prototype.foo = bar;
別の方法では、実のところこれをするための標準的方法ですが（ECMAScript 仕様を参照してください）、コンストラクタ関数のプロトタイププロパティを通して HTMLImageElement のプロトタイプにアクセスし変更できます:
HTMLImageElement.prototype.foo = bar;

And a third way (also per the ECMAScript specification) through which one can access the prototype of an object is through the constructor property's prorotype property:
document.images[0].constructor.prototype.foo = bar;
3番めの方法としては（これも ECMAScript 仕様によるのですが）、コンストラクタのプロパティのプロトタイププロパティを通してオブジェクトのプロトタイプへアクセスことができます:
document.images[0].constructor.prototype.foo = bar;

Note though, the above does not yet work in Mozilla.
しかしこの方法は まだ Mozilla で機能しません。

JavaScript-DOM Prototypes in Mozilla 草稿化 3

原文：青色表示
訳文：黒色表示
注記/訂正： 赤色表示

The prototype objet that XPConnect creates for the classes that have classinfo are shared within a scope (window). Because of this, the following is true (|img1| and |img2| are two different image objects in the same document):
img1.__proto__ === img2.__proto__

class info を備えているクラスへ XPConnect が生成するプロトタイプオブジェクトは領域（window）内で共用されます。このお陰で、以下の条件は真となります。 (|img1| と |img2| は同じドキュメントの異なる2 つのイメージオブジェクトです):
img1.__proto__ === img2.__proto__

If |img1| comes from one document and |img2| comes from another document then the above is not true, both protos would look identical, but they'd be two different JSObject's.

|img1| と |img2| が別別のドキュメントに由来するならば、上記の条件は真になりません。2 つのプロトタイプは同じに見えますが、2 つの異なる JSObject です。

This sharing of prototypes lets users do cool things like modify how all instances of a given class works by modifying the prototype of one instance. As an example:This sharing of prototypes lets users do cool things like modify how all instances of a given class works by modifying the prototype of one instance. As an example:
function bar()
{
alert("Hello world!");
}

document.images[0].__proto__.foo = bar;

このようにプロトタイプを共有化し、ユーザは、１つのインスタンスのプロトタイプを変更することで、所定のクラスのすべてのインスタンスがどのように機能するかについて、変更など素晴らしいことが実現できます。例を見ましょう:
function bar()
{
alert("Hello world!");
}

document.images[0].__proto__.foo = bar;

JavaScript-DOM Prototypes in Mozilla 草稿化 2

原文：　 青色表示
訳文：　 黒色表示
注記/訂正： 赤色表示


var obj = document.images[0];

Here, obj will not really have any properties (except for the standard JSObject properties such as constructor, and the non-standard __parent__, __proto__, ...), all the DOM functionality of |obj| comes from obj's prototype (obj.__proto__) that XPConnect sets up when exposing the first image in |document| to JS. Here's a few of the properties of obj's prototype:

obj.__proto__
- parentNode (getter Function)
- src (getter and setter Functions)
- getElementsByTagName (Function)
- TEXT_NODE (Number property, constant)
- ...


var obj = document.images[0];

ここでは、 obj は実際プロパティを備えることはありません（例外として constructor などの標準の JSObject のプロパティや非標準の __parent__、__proto__などがあります）。 |obj| のすべての DOM の機能は、XPConnect が |document| で JS へ最初のイメージを示す時に設定する obj のプロトタイプ (obj.__proto__) から発生します。以下に obj のプロトタイプのプロパティのいくつかを示します:

obj.__proto__
- parentNode (getter Function)
- src (getter and setter Functions)
- getElementsByTagName (Function)
- TEXT_NODE (Number property, constant)
- ...


All those properties come from the interfaces that the C++ image object (nsHTMLImageElement) implements and chooses to expose to XPConnect through the object's class info. One of these interfaces is nsIDOMHTMLImageElement, others are nsIDOMNSHTMLImageElement (Netscape extensions to the standard interface), nsIDOMEventTarget, nsIDOMEventListener, nsIDOM3Node, and so on...

これらのプロパティのすべては、 C++ イメージオブジェクト (nsHTMLImageElement) がオブジェクトの class info を通して XPConnect へ示すのに実装し選択するインターフェイスに由来します。これらのインターフェイスのひとつが nsIDOMHTMLImageElement であり、その他に nsIDOMNSHTMLImageElement (標準インターフェイスへの Netscape の拡張)、 nsIDOMEventTarget、nsIDOMEventListener、 nsIDOM3Node などがあります。

JavaScript-DOM Prototypes in Mozilla 草稿化 １

三月になり我が家の小さな花壇にチューリップの芽が出てくると、春が曲がり角の手前まで来ていることが予感されます。近頃は運動不足で、仕事場に篭ってクラッシク音楽を聴いてばかりいると、体重の増加ばかりが気になります。

夜夫婦で歩いている人たちをよく見かけますが、私たちも歩こうねと家内と話をしながらなかなか実現せずに、とうとう花粉症の季節となりました。すると、ますます屋外を歩くのが億劫になります。結局摂取した栄養分を燃焼できないまま、夫婦とも係数でいうと肥満の領域の側に足をふみいれました。(・_・、
-----------------------------------------------------------------------------

リンクをたどって DOM 周辺の文書を漁っているうちに、タイトルの文書が和訳されていないようなので、早速 Mozilla Japan 和訳部門のフォーラムに予約宣言をし、そそくさと和訳を開始しました。

原文：　 青色表示
訳文：　 黒色表示
注記/訂正： 赤色表示


JavaScript-DOM Prototypes in Mozilla
Prototype setup on an XPConnect wrapped DOM node in Mozilla

When a DOM node is accessed from JS in Mozilla, the native C++ DOM node is wrapped using XPConnect and the wrapper is exposed to JS as the JS representation of the DOM node. When XPConnect wraps a C++ object it will create a JSObject that is unique to this C++ object. In the case where the C++ object has class info (nsIClassInfo), the JSObject is a more or less empty JSObject which is not really that special. All the methods that are supposed to show up on this JSObject are actually not properties of the object itself, but rather properties of the prototype of the JSObject for the wrapper (unless the C++ object's class info has the flag nsIXPCScriptable::DONT_SHARE_PROTOTYPE set, but lets assume that's not the case here). As an example of this let's look at an HTML image element in a document.

var obj = document.images[0];


Mozilla における JavaScript-DOM プロトタイプ
Mozilla で XPConnect によりラップされた DOM ノードに設定されたプロトタイプ

DOM ノードが Mozilla の JS（ジャバスクリプト） からアクセスされる時、ネイティブの C++ の DOM ノードは　XPConnect を使ってラップされます。ラッパーは DOM ノードの JS の代理として JS へ示されます。XPConnect が C++ オブジェクトをラップする時、XPConnect はこの C++ オブジェクトへ一意の JSObject を生成します。この時 C++　オブジェクトが class info (nsIClassInfo) を備えていると、JSObject は大体、実際はそれほど特殊でない空の JSObject です。この JSObject に現れることになるすべてのメソッドは、実のところオブジェクトそのもののプロパティでなく、ラッパーに対する JSObject のプロトタイプののプロパティです（その時 C++ オブジェクトが nsIXPCScriptable::DONT_SHARE_PROTOTYPE のセットを備えていなければですが、ここでは、備えてないとします）。この例としてドキュメントの HTML イメージ要素を見てみましょう。

var obj = document.images[0];

Mapping DOM Objects to their C++ classes-21

長かった一連の翻訳も本日で終わる。すべて、”Mapping DOM Objects to their C++ classes”のサブディレクトリにある文書である。翻訳対象となる原文のパターンが同じなので、それほど大変な翻訳作業ではないが、DOM のクラスやインターフェイスの紹介になっていると思う。翻訳しながら、勉強させてもらった。

原文：　 青色表示
訳文：　 黒色表示
注記/訂正： 赤色表示

Class: nsHTMLIFrameElement

File: content/html/content/src/nsHTMLIFrameElement.cpp

Inherits from the following classes:

* nsGenericHTMLContainerElement : content/html/content/src/nsGenericHTMLElement.cpp

Implements the following interfaces:

* nsIDOMHTMLIFrameElement : dom/public/idl/html/nsIDOMHTMLIFrameElement.idl
* nsIChromeEventHandler : layout/base/public/nsIChromeEventHandler.idl


Iframe

Iframe オブジェクトは HTML の "iframe" タグを操作する時使われます。W3C はそれを DOM レベル 1 HTML spec. で導入しました

クラス: nsHTMLIFrameElement

ファイル: content/html/content/src/nsHTMLIFrameElement.cpp

以下のクラスを継承します:

* nsGenericHTMLContainerElement : content/html/content/src/nsGenericHTMLElement.cpp

以下のインターフェイスを実装します:

* nsIDOMHTMLIFrameElement : dom/public/idl/html/nsIDOMHTMLIFrameElement.idl
* nsIChromeEventHandler : layout/base/public/nsIChromeEventHandler.idl
* nsIDOMEventListener : dom/public/idl/events/nsIDOMEventListener.idl