Mozilla DOM Hacking Guide: Introduction to XPCOM21

今日でタイトルの文書は最終回。
プログラマでない私が、プログラムの勉強を続けながら Mozilla Org. の文書を翻訳させてもらっている。一人よがりの翻訳にならないように、ご意見や、ダメ出しを含めたアドバイス大歓迎。

翻訳対象文書が、オープンソースの開発関連文書という一般向けするものではないので、それほど多くの人に読んではもらえない。しかし、翻訳を続けながら今のところ、このブログも出来る限り継続したいと思う。少しでも、上達したいと思う限り修行は続く。 m(__)m

てなわけで本日は、草稿として最後の部分の仕上をする。
-------------------------------------------------------------------

To illustrate the inherited implementation of an interface, let's take a look at the real class that implements the HTML Anchor Element. It is nsHTMLAnchorElement. We can see that the inheritance chain for the real classes looks like this:

nsGenericElement -> nsGenericHTMLElement -> nsGenericHTMLContainerElement -> nsHTMLAnchorElement


インターフェイスが継承された時の実装を解説するのに、HTML Anchor Element　を実装している実際のクラスを見てみましょう。調べるのは nsHTMLAnchorElement です。実際のクラスの継承の連鎖はこのようになっています:

nsGenericElement -> nsGenericHTMLElement -> nsGenericHTMLContainerElement -> nsHTMLAnchorElement


We can see this in the class definitions:

class nsHTMLAnchorElement : public nsGenericHTMLContainerElement
class nsGenericHTMLContainerElement : public nsGnericHTMLElement
class nsGenericHTMLElement : public nsGenericElement


クラスの定義は以下のようになっています:

class nsHTMLAnchorElement : public nsGenericHTMLContainerElement
class nsGenericHTMLContainerElement : public nsGnericHTMLElement
class nsGenericHTMLElement : public nsGenericElement


Looking at the class definitions, we can see that nsGenericHTMLElement and nsGenericHTMLContainerElement don't implement any interface directly. However nsGenericElement does:

class nsGenericElement : public nsIHTMLContent


クラスの定義を見ると、nsGenericHTMLElement と nsGenericHTMLContainerElement 直接インターフェイスを実装していません。しかし、nsGenericElement は実装しています:

class nsGenericElement : public nsIHTMLContent


This of course means that nsGenericElement implements the nsIHTMLContent interface. The interface inheritance chain for nsIHTMLContent looks like this:

nsISupports -> nsIContent -> nsIStyledContent -> nsIXMLContent -> nsIHTMLContent


これはもちろん nsGenericElement が nsIHTMLContent　インターフェイスを実装していることになります。 nsIHTMLContent への継承の連鎖は以下のようになります:

nsISupports -> nsIContent -> nsIStyledContent -> nsIXMLContent -> nsIHTMLContent


nsGenericElement has to implement all of the above interfaces, and all the real classes inheriting from nsGenericElement will automatically implement all those interfaces. This is consistent with the rules we have defined earlier in this paragraph.


nsGenericElement は上記のすべてのインターフェイスを実装しなくてはなりません。そして、nsGenericElement を継承するすべての実際のクラスは自動的にこれらのインターフェイスを実装します。 この事はすでにこの段落で定義した規則と一致しています。


Resources of interest:
The XPIDL reference
Mapping DOM Objects to their C++ class
Modularization techniques

関連する参照先:
xpidl コンパイラ
Mapping DOM Objects to their C++ class
モジュール化の方法

この文書はMozilla Japan Org. で草稿公開されることになります。

m(__)mm(__)mm(__)mm(__)mm(__)mm(__)mm(__)mm(__)mm(__)mm(__)m

Mozilla DOM Hacking Guide: Introduction to XPCOM20

昨日より続く。

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

Example

Let's take a look at a simple example, the HTML Anchor Element. First, let's illustrate the interface inheritance rules. If we look at nsIDOMHTMLAnchorElement (which contains the methods and properties defined by the W3C for this element), we can see that it inherits from another interface, nsIDOMHTMLElement:

interface nsIDOMHTMLAnchorElement : nsIDOMHTMLElement


サンプル

簡単なサンプルである HTML Anchor Element を見てみましょう。　最初に、インターフェイスの継承規則を解説しましょう。nsIDOMHTMLAnchorElement(HTML Anchor Element のために　W3C によって定義されたメソッドやプロパティを備えていますが)を見れば、それが別のインターフェイスである nsIDOMHTMLElement を継承してるのが分かります:

interface nsIDOMHTMLAnchorElement : nsIDOMHTMLElement


This means that whatever class implements the nsIDOMHTMLAnchorElement interface will also have to implement the nsIDOMHTMLElement interface. If we look at nsIDOMHTMLElement, we can see that it inherits from nsIDOMElement, which inherits from nsIDOMNode, which inherits from nsISupports. Any class implementing nsIDOMHTMLAnchorElement will have to implement all the mentioned interfaces, because of inheritance. How the interfaces are implemented is described in paragraph 1.E.d.

すなわち、nsIDOMHTMLAnchorElement　インターフェイスを実装するクラスはすべて nsIDOMHTMLElement インターフェイスも実装しなければならないということです。 nsIDOMHTMLElement　を見ると、それが nsIDOMElement　を継承しており、後者は nsIDOMNode を継承しており、さらに nsIDOMNode が、nsISupports　を継承しているのが分かります。 nsIDOMHTMLAnchorElement は継承のために今述べたすべてのインターフェイスを実装しなければなりません。インターフェイスの実装方法は 1.E.d.の段落を参照してください。

The interface inheritance shows that the top-level interface is nsISupports. All interfaces have to inherit from nsISupports, directly or indirectly. It defines three methods, AddRef(), Release(), and QueryInterface(), which is explained in Section 1.B. nsISupports rests peacefully in xpcom/base/, unmodified since 1999. For more information about XPCOM interfaces and nsISupports, please read the Modularization techniques guide.

インターフェイスの継承によってトップレベルのインターフェイスが nsISupports　であることが分かります。すべてのインターフェイスは直接的にまた間接的に nsISupports　を継承しなければなりません。このインターフェイスは　1.B. の節で説明された AddRef()、 Release()、QueryInterface()　という3　つのメソッドを定義します。 nsISupports は xpcom/base/　で　1999　年以降変更されることなく平和に息づいています。 XPCOM インターフェイスと nsISupports　については、モジュール化の方法をご参照ください。


この長いチュートリアルもいよいよ明日草稿として完成します。本当に長かったなもし。(・_・、

Mozilla DOM Hacking Guide: Introduction to XPCOM19

今日車がパンクした。いつものように家内を乗せてスーバーまで買い物に行こうと車と発進させたが、どうも様子がおかしい。車台の下で何か音がする。静かに走らせると特に問題がないようである。しかし、速度を上げると車の下でなにか引きずっているような音がする。家内が家に戻ろうかと言ったが、交通の多い道でUターンするのもままならない。停車するスペースもない。そのまま、ドラッグストアの駐車場まで走らせた。停車して車を点検してみると、一見してパンクと分かった。左前輪のタイヤが潰れていた。

ジャッキをトランクルームから取り出してタイヤの交換作業に入る。車体をジャッキアップするのに苦労したものの、なんとか応急用のタイヤと交換できた。所要時間１０分とかかっていない。家内の買い物時間のほうがはるかに長かった。これも、自分でタイヤのローテーションを５千キロごとに行っていたお陰である。手馴れたものさ。(^_^ゞ

買い物を済ませて帰宅した後、近所のガソリンスタンドまでパンクの修理に行った。ところが、タイヤのダメージが大きいので、交換を勧められた。ホイールからタイヤを外して、その内側の状態をチェックしてもらうと、損傷が大きくタイヤの機密性が完全に確保できないと言う。最悪、高速走行時にバーストの可能性があるという。そういわれて、パンク修理で済ませてくれと言うのはかなり勇気の要ることだったろう。結局１万円強の臨時出費となった。(/_・、)
----------------------------------------------------------------------------
原文：　 青色表示
訳文：　 黒色表示
注記/訂正： 赤色表示

Theory

Now that we know what interface inheritance means, we can look at more generic cases. We will first see this in a very theoretical way, and then we will use the nsHTMLAnchorElement example to illustrate the discussion.

理論

インターフェイスの継承がどういうことであるか分かったので、もっと一般的なケースを調べてみましょう。最初にごく理論的に見て、次に nsHTMLAnchorElement のサンプルを使って議論を解説します。

Let's assume we have a DOM object Foo, implemented by the real class nsFoo. We also have another real class, nsBar, as well as three interfaces, nsIFoo1, nsIFoo2, and nsIFoo3. The situation is the following:

nsBar <- nsIFoo1
|
V
nsFoo <- nsIFoo2 <- nsIFoo3


実際のクラス nsFoo によって実装されている DOM オブジェクト Foo があると仮定しましょう。nsIFoo1、nsIFoo2、nsIFoo3 の 3 つのインターフェイス に加えて別の実際のクラス nsBar もあるとしましょう。この状況は以下のようになります:

nsBar <- nsIFoo1
|
V
nsFoo <- nsIFoo2 <- nsIFoo3


In this situation, the nsIFoo2 interface inherits from the nsIFoo3 interface, as described above. nsFoo implements nsIFoo2, and thus also nsIFoo3, and nsBar implements nsIFoo1. The real class nsFoo inherits from the other real class nsBar. The rules describing inheritance are the following:

この状況で上記に記されているように nsIFoo2 インターフェイスは nsIFoo3 インターフェイスを継承します。 nsFoo は nsIFoo2 を実装しその結果 nsIFoo3 も実装します。nsBar は nsIFoo1 を実装します。実際のクラス nsFoo は別の実際のクラス nsBar を継承します。継承を説明する規則は以下のようになっています:

* nsFoo implements nsIFoo1 automatically, because it inherits from a class that already implements nsIFoo1.
* nsBar has to implement nsIFoo1.
* nsFoo has to implement nsIFoo2 and nsIFoo3, unless they are forwarded to nsBar. Interface forwarding is described in Section 1.E.d.

* nsFoo は自動的に nsIFoo1 を実装します。というのは、すでに nsIFoo1 を実装しているクラスを継承しているからです。
* nsBar は nsIFoo1　を実装しなければ なりません。
* nsFoo は、nsIFoo2 と nsIFoo3　が nsBar へ転送 されない限りは、nsIFoo2 と nsIFoo3　を実装しなければなりません。インターフェイスの転送については 1.E.d　の節で解説されています。


These rules are pretty simple, and are widely used in the DOM code. It gets trickier with a lot of classes and interfaces, but you can always reduce the problem to the above situation.

これらの規則はとても簡単であり DOM のコードで広く使われています。クラスやインターフェイスが増えるにつれてコードはより複雑になりますが、上記の方法を使えば必ず問題を低減することが出来ます。

さて、未熟な翻訳を衆目に晒して早19日、もう1、2日で草稿アップの状態までもって行けそうだ。See you! (^-^)/~~~~

Mozilla DOM Hacking Guide: Introduction to XPCOM18

本日はモーツアルトの誕生日だそうである。生誕250年。テレビやラジオでこの事を今日すでに2、3回聞かされた。なぜ？

それは、日本人がモーツアルトが大好きだからです。オーストリア以外のヨーロッパの国はともかく、他の国の作曲家の誕生日がこれほど話題になる国は日本だけです。ほぼ間違いない。。。日本の大作曲家、山田耕作も、滝廉太郎もモーツアルトには勝てない。

昔大学の教養課程で履修した音楽の講義で、先生に言われたことを思いだす。日本人のモーツアルト好きは、もし本国のオーストリアでモーツアルトの音楽が演奏されなくなったとしても、日本へくればそれが聴けるであろうというくらいなのだと。

確かにモーツアルトの音楽は美しい。人の心を捉えて放さない。そしてそのちょうど良い長さ。シンフォニーも、コンチェルトも、弦楽四重奏も30分以内に終わる。。。しかし、日本人が彼を好きな最大の理由は、やはりその天才であり夭折した人生への感銘だろう。日本人は悲劇の主人公が大好きなのだ。天才の割には、幸せといえなかった人生。映画アマデウスがどこまで、彼の人生の真実を描いているかは分からないが、そこに描かれたのはけっして幸福といえない人生を送った天才の話だった。

今日のBGMは、もちろんモーツアルト。弦楽四重奏16番　K428 イタリア弦楽四重奏団、明るい。。。
--------------------------------------------------------------

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

F. Interface inheritance (Advanced topic)

The inheritance model in Mozilla is of course the same as the class inheritance model of C++. If you are familiar with object-oriented programming you will have no problem understanding this discussion.

F. インターフェイスの継承(中級編)

Mozilla における継承のパターンは当然 C++ の継承パターンと同じです。オブジェクト指向のプログラミングに詳しい方であれば、この議論の理解には問題はないでしょう。

Raw interface inheritance

The first concept is easy to grasp, it's the "interface inheritance". If we look at any interface definition, in XPIDL or as a header, we can see that it always inherits from another interface. For instance, we have the following "chain" for the nsIDOMHTMLAnchorElement interface:
nsISupports -> nsIDOMNode -> nsIDOMElement -> nsIDOMHTMLElement -> nsIDOMHTMLAnchorElement.

生のインターフェイスの継承

最初の概念は理解するのは難しくありません。それは、”インターフェイスの継承”です。XPIDL や header にインターフェイスの定義があれば、そのインターフェイスは必ず他のインターフェイスを継承しています。たとえば、 nsIDOMHTMLAnchorElement インターフェイスにとって以下の”連鎖”を備えています:
nsISupports -> nsIDOMNode -> nsIDOMElement -> nsIDOMHTMLElement -> nsIDOMHTMLAnchorElement.

This means that, if a class implements one of the interfaces in the chain, it has to also implement all the ancestors of that interface. For example if a real class implements nsIDOMElement, it also has to implement nsIDOMNode and nsISupports.

すなわち、クラスが連鎖にあるインターフェイスの 1 つを実装すると、そのクラスは実装されたインターフェイスのすべての祖先を実装しなければならないという事です。たとえば、実際のクラスが、nsIDOMElement を実装するなら、そのクラスは nsIDOMNode と nsISupports をも実装しなければならないのです。

さてさて、いよいよ最後の節まで来た。長い文書であるが、もう少しの辛抱だ。先は長くない。。。

Mozilla DOM Hacking Guide: Introduction to XPCOM17

昨日の続き！

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

nstead of having to type the three methods and forward them to nsBar, we can use the "Interface forwarding macro", NS_FORWARD_NSIFOO.

#define NS_FORWARD_NSIFOO(_to) \
NS_IMETHOD GetProp() { return _to GetProp(); } \
NS_IMETHOD SetProp() { return _to SetProp(); } \
NS_IMETHOD Meth() { return _to Meth(); }


この時 3 つのメソッドをタイプして nsBar へ送らなくても、代わりに”インターフェイス転送マクロ”の NS_FORWARD_NSIFOO を使用できます。

#define NS_FORWARD_NSIFOO(_to) \
NS_IMETHOD GetProp() { return _to GetProp(); } \
NS_IMETHOD SetProp() { return _to SetProp(); } \
NS_IMETHOD Meth() { return _to Meth(); }


The meaning of this macro is easy to grasp. It will forward all the methods on the nsIFoo interface to the implementation on the _to class.

このマクロの意味を理解するのは簡単です。 _to クラスの実装に対して nsIFoo インターフェイスのすべてのメソッドを転送します

Application to nsIDOMFabian: we could code our two functions in nsDocument, then forward nsIDOMFabian to nsDocument from nsHTMLDocument. This would allow us to be able to re-use the nsDocument code in nsXMLDocument, for example. This technique is already used for most of the document methods.

nsIDOMFabian のアプリケーション: nsDocument で 2 つの関数をコード化し nsHTMLDocument から nsDocument へ nsIDOMFabian を転送できます。こうする事で例えば、 nsXMLDocument で nsDocument のコードを再利用することもできます。この技術はすでに大抵の document 関数で使われています。

// File nsDocument.h:
class nsDocument : public ...
{
// ...
NS_IMETHOD Fabian(void);
NS_IMETHOD GetNeat(PRBool *aNeat);
// ...
}

// File nsDocument.cpp:
nsDocument::Fabian()
{
// ...
}
nsDocument::GetNeat(PRBool *aNeat)
{
// ...
}

// File nsHTMLDocument.h:
class nsHTMLDocument : public ... ,
public nsIDOMFabian
{
// ...
NS_FORWARD_NSIDOMFABIAN(nsDocument::)
// ...
}

//nsHTMLDocument.cpp　では何も必要でない

This was an easy example of "Interface forwarding". These two ways are the most common to implement an interface in the DOM. There are other ways that are a little more complicated, not worth detailing here.

これは "インターフェイス転送" の簡単な例です。これらの2つの方法は DOM でインターフェイスを実装する最も一般的方法です。もう少し複雑な他の方法がありますが、ここでは扱いません

Important note: the nsISupports interface, implemented by all the DOM classes, CANNOT be implemented with forwarding or declaration macros. Special macros are provided to implement nsISupports

重要な注記: すべての DOM クラスによって実装される nsISupports インターフェイスは転送マクロや宣言マクロを使って実装されません。nsISupports の実装には特別なマクロが提供されます

This closes this tutorial about how to add a new interface. Simply make a full rebuild. I recommend building distclean. Your methods will not be available from JavaScript, however, because nsIDOMFabian is not in the Class Info. Please see the User's guide of Class Info to learn how to add it.

新しいインターフェイスの追加方法についてのチュートリアルはここで終わりです。ただ全面的に作り直してください。distclean をビルドするといいでしょう。しかし、JavaScript からはあたたのメソッドは有効になりません。というのは、nsIDOMFabian は Class Info. にないからです。その追加方法に関してはClass Info の使い方を参照してください。

Snoopy
Sleepy　

Mozilla DOM Hacking Guide: Introduction to XPCOM16

寒いとつい億劫になって庭の手入れもおろそかになった結果、雑草がぼうぼうのまま冬枯れてしまった。すぐにしなければならないのは、草刈り、バラの剪定と施肥。きちんとしておかないと、春になって可憐な花をめでることが出来ない。

ところで、バラを美しく咲かせようとすると、剪定や施肥、駆虫処理など手がかかるが、花のなかには何の手入れもしないのに、毎年春になると常連客のように必ず顔を見せる宿根草がある。ヒマヤラユキノシタ：キャベツみたいな大きな葉を持ち、濃いピンクの小さな花を咲かせる。家内の実家から株分けをしてもらって早くも10年。ほとんど毎年咲いている。

株をくれた義母はもういない。花だけが毎年我が家に春を告げに訪れる。その間、子は育ち、義母は故人となり、時は確実に経過した。今年もあの花は咲くであろうか。妻も私も10歳年を取ったが、毎年見る花は永遠に同じ花のように思える。変わらない植物が変わっていく人の営みを見つめているかのようである。ああ、所業無常。(・O・)
-----------------------------------------------------------------------

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

Let's assume we have the real class nsFoo which inherits from the real class nsBar. Let's also assume that nsFoo implements the interface nsIFoo. One possible way for nsFoo to implement nsIFoo is to forward the methods on the interface to the implementation of those methods on the class nsBar.

// Interface nsIFoo in XPIDL (stripped down)　
interface nsIFoo {
attribute type prop;
void meth();
};

class nsBar {
NS_IMETHOD GetProp();
NS_IMETHOD SetProp();
NS_IMETHOD Meth();
};

class nsFoo : public nsIFoo,
public nsBar {
// definition of the nsFoo class
};

nsFoo::GetProp() { return nsBar::GetProp(); }
nsFoo::SetProp() { return nsBar::SetProp(); }
nsFoo::Meth() { return nsBar::Meth(); }


実際のクラス nsBar を継承する実際のクラス nsFoo があると仮定しましょう。また nsFoo が nsIFoo インターフェイスを実装するとも仮定しましょう。nsFoo が nsIFoo を実装する可能性の 1 つは、 nsIFoo インターフェイスのメソッドを、クラス　nsBar のこれらの同じメソッドの実装において、転送することです

//XPIDLでの nsIFoo インターフェイス（最低限の実装）　　　
interface nsIFoo {
attribute type prop;
void meth();
};

class nsBar {
NS_IMETHOD GetProp();
NS_IMETHOD SetProp();
NS_IMETHOD Meth();
};

class nsFoo : public nsIFoo,
public nsBar {
//nsFoo クラスの定義　
};

nsFoo::GetProp() { return nsBar::GetProp(); }
nsFoo::SetProp() { return nsBar::SetProp(); }
nsFoo::Meth() { return nsBar::Meth(); }


For such code to work, nsBar of course has to implement GetProp, SetProp, and Meth. Note that nsBar implements the methods of the interface nsIFoo, but does not inherit from that interface. This is the only case where you would use interface forwarding.

このようなコードが機能するのに nsBar はもちろん GetProp、 SetProp、 Meth を実装しなければなりません。注意が必要なのは、nsBar は nsIFoo インターフェイスのメソッドを実装しますが、nsIFoo インターフェイスを継承しません。 そしてこの場合だけインターフェイス転送を使用できます。 　

To be continued tomorrow! Bye.

Mozilla DOM Hacking Guide: Introduction to XPCOM15

今朝お湯の供給が止まった。湯沸かし器の配管が戸外で凍結したらしい。応急処置のために、配管をビニールマットで覆わねば。やれやれ(・_・、

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

Modification of the class declaration and class body:

#include "nsIDOMFabian.h"
class nsHTMLDocument: public ... ,
public nsIDOMFabian
{
// ...
NS_DECL_NSIDOMFABIAN
// ...
};


クラス宣言とクラス本体の変更:

#include "nsIDOMFabian.h"
class nsHTMLDocument: public ... ,
public nsIDOMFabian
{
// ...
NS_DECL_NSIDOMFABIAN
// ...
};


First we have to declare nsHTMLDocument as inheriting from nsIDOMFabian. Then, in the class public interface, we use the macro NS_DECL_NSIDOMFABIAN to declare the methods necessary to the implementation of our interface. Remember, this macro is auto-generated by the XPIDL compiler. It declares all the methods that will be implemented on the class for the nsIDOMFabian interface. A typical NS_DECL_NSIFOO macro looks like this:

#define NS_DECL_NSIFOO \
NS_IMETHOD GetBar();


最初に nsIDOMFabian を継承する時、nsHTMLDocument クラスを宣言する必要があります。それからクラスの public なインターフェイスで、マクロの NS_DECL_NSIDOMFABIAN を使ってインターフェイスの実装に必要なメソッドを宣言します。このマクロは XPIDL コンパイラによって自動生成されることを憶えてください。　それは　nsIDOMFabian インターフェイスのためのクラスで実装されるメソッドをすべて宣言します。典型的な NS_DECL_NSIFOO マクロは以下のようになっています:

#define NS_DECL_NSIFOO \
NS_IMETHOD GetBar();


This macro has to be used in the class definition, and means that the class nsFoo will have a method nsFoo::GetBar(). Now that the functions are declared, we can finally code them.

このマクロはクラスの定義で使われる必要があり、nsFoo クラスは nsFoo::GetBar() メソッドを備えることになります。. 関数が宣言されたので、最後にコード化が可能になります。



There are various possibilities to implement the functions. The first one is the most straightforward. The functions we have to implement are nsHTMLDocument::Fabian() and nsHTMLDocument::GetNeat(). So let's just code them.
NS_IMETHODIMP nsHTMLDocument::Fabian(void)
{
printf("Hello from the nsIDOMFabian interface\n");
// Whatever you want...
return NS_OK;
}

NS_IMETHODIMP nsHTMLDocument::GetNeat(PRBool *aNeat)
{
if(!aNeat) {
return NS_ERROR_NULL_POINTER;
}

nsresult rv = Fabian();
if( rv == NS_OK ) {
*aNeat = PR_TRUE;
} else {
*aNeat = PR_FALSE;
}
return NS_OK;
}


関数を実装するのに様々な可能性があります。最初の方法は最も簡単です。実装しなければならない関数は nsHTMLDocument::Fabian() と nsHTMLDocument::GetNeat() です。それでは、コード化してみましょう。

NS_IMETHODIMP nsHTMLDocument::Fabian(void)
{
printf("Hello from the nsIDOMFabian interface\n");
　　// 何が欲しくても...
return NS_OK;
}

NS_IMETHODIMP nsHTMLDocument::GetNeat(PRBool *aNeat)
{
if(!aNeat) {
return NS_ERROR_NULL_POINTER;
}

nsresult rv = Fabian();
if( rv == NS_OK ) {
*aNeat = PR_TRUE;
} else {
*aNeat = PR_FALSE;
}
return NS_OK;
}


This code is of course written in nsHTMLDocument.cpp. The functions are very simple, but it is only a
^*1proof-of-concept. A second possibility is to use the "Interface forwarding macro". This macro is also auto-generated by the XPIDL compiler. Below is the theory behind interface forwarding, followed by an example of nsIDOMFabian.

このコードはもちろん nsHTMLDocument.cpp で書かれます。関数はとても簡単であり、ただ^*1概念を説明しているだけです。2 番めの可能性は "インターフェイス転送マク"を使うことです。このマクロはまた XPIDL コンパイラによって自動生成されます。以下はインターフェイス送信の背景にある理論で、そのあとに来るのは nsIDOMFabian です。

^*1proof-of-concept→コンセプト（概念）を実証するためのもの

The end is near,
I am here. m(__)m

Mozilla DOM Hacking Guide: Introduction to XPCOM14

昨日の女房との会話：
”２、３年で自動販売機でのタバコの購入が制限されるそうよ。ID カードのようなものがないとタバコが買えなくなるみたい”

むしろいままで、そうでなかったのが遅すぎたように思う。購入の制限が未成年を対象としていることは間違いない。もちろんそれが、万全の対策にならないのはしょうがないが、ある程度の効果は期待できるかもしれない。

昔私の通っていた私大の学食での光景を思い出す。近くに付属高校があるのでそこの生徒が利用に来ていた。彼らの中には、食堂で堂々と喫煙する者も少なくはなかった。しかし誰も注意しない。教師もおそらく知っていたのだろうが見てみぬふりであった。地方の公立高校出身の私にとってそれは異様な風景だった。当時、私の卒業した高校で生徒の喫煙が見つかると、退学と言わないまでも停学になるのがふつうだったから。女房も高校時代まわりで喫煙する同級生はいなかったという。上の話を聞かせると、東京は進んでいたのね、と言った。彼女は関西出身である。

しかし今の時代、高校生の喫煙や飲酒はどうも日常的になっているようだ。長女の通っていた学校でも、部室や寮でのそれは公然の秘密だったという。そして大学に入り、新入生歓迎会での飲酒へと続く。法律違反ということで、ホリエモンとどこが違う？有名人であれば、責められるが、一般人の違法行為は”公然の秘密”ということなのかな(・_・?。まあスケールは違いますけどね。
---------------------------------------------------------------

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

Let's take a closer look at how interfaces are implemented. We already know that an interface has to be implemented by a concrete C++ class. This class can implement multiple interfaces, directly or through inheritance (see the next section for a discussion of inheritance). We also saw that an interface defined in XPIDL contains methods and attributes, which are transformed into C++ functions by the XPIDL compiler. The class that implements the interface has to explicitly implement each method and implement the setter and the getter of each attribute defined on the interface. If the attribute is read-only, only a getter is necessary, of course.

インターフェイスの実装方法を詳細に観てみましょう。 C++ の具象クラスよってインターフェイスが実装されなければならないことをすでに知っています。このクラスは複数のインターフェイスを直接または継承によって実装できます（継承の議論は次の節を参照してください）。また私たちは XPIDL で定義されたインターフェイスがメソッドと属性を保持し、これらは XPIDL コンパイラによって C++ の関数に変換されることも知りました。インターフェイスを実装するクラスは明示的に、インターフェイスで定義された各メソッドを実装し、各属性の setter と getter 実装しなければなりません。もし属性が read-only であればもちろん getter だけが必要になります。

I have chosen to implement nsIDOMFabian in the nsHTMLDocument class, which is defined in nsHTMLDocument.h. There are three things to do: modify the class declaration, the class body, then code the functions declared on the interface.

nsHTMLDocument.h で定義されている nsHTMLDocument クラスに nsIDOMFabian を実装することにしました。すべきことが 3 つあります: クラスの宣言を変更すること、クラスの本体を変更すること、インターフェイスで宣言された関数をコード化することです。

コーディングは、明日にする。
To be continued tomorrow!

Mozilla DOM Hacking Guide: Introduction to XPCOM13

今日は日帰りで女房と温泉へ行ってきた。午前中は寒い薄ら曇りで外出するのも億劫であったが、彼女がその気になっているので出かけることにした。先日知人から無料招待券を２枚いただいたので、昨晩、明日は温泉に行こうと言ったのはこの私。(^-^;

子供二人家に残して行った。長女は大学の学年末試験のため珍しく真剣に勉強中。長男はギターを弾いていた。いずれにしても、親と一緒に温泉へ行く年頃ではない。長男にお前も行くかと愛想を言ったが、無言。明らかにとまどっている。やめておくか、と言ったら、首を立てに振った。

温泉に着いたときは、団体客で騒々しかったが、一風呂浴びて大広間に戻ってくると人の数が減っていた。急に静かになった。風呂に入るとにわかにすることがなくなったので、持参した”日経ソフトウエア”を読んでいた。そのうち、女房が風呂から戻って来て、２人でめいめい本を読んでいたが、なんとなくつまらない。隣の席で昼寝をしている人のいびきが聞こえる。風呂はよかったが、もう一度入る気はしない。結局、その近所で評判の温泉饅頭をお土産に買って帰ることになった。

途中、開店したばかりの衣料品店に寄りたいと言われたので、住所を頼りに店を探したがなかなか見つからない。諦めて、帰ろうとして折り返し戻った道の近くで、その店の真新しい看板を見つけた。

そんなわけで、女房の買い物にもつきあったお陰で、今日は良い亭主だったかも。(^-^)
----------------------------------------------------------------------------

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

E.c Build System

This is the really easy part: it's just copying what's already there. First, we have to decide in which directory we will place our interface. The most logical choice for us is in dom/public/idl/html, where all the HTML interfaces live. Next, we have to add nsIDOMFabian.idl to all the makefiles of this directory. This includes, if needed, "MANIFEST", "makefile.win", "Makefile.in", etc... Simply copy the existing entries for nsIDOMFabian. Warning: In Makefiles, there is a mix of TABS and whitespaces. Make sure you copy exactly the other entries.

E.c ビルドシステム

ここはとても簡単なところです：すでにあるものをコピーするだけですから。最初にどのディレクトリへインターフェイスを置くか決めなければなりません。最も論理的選択は、すべての HTML インターフェイスが存在する dom/public/idl/html です。次に、このディレクトリのすべての makefiles へ nsIDOMFabian.idl を追加しなければなりません。これには必要であれば、"MANIFEST"、 "makefile.win"、"Makefile.in" などが含まれます。単に nsIDOMFabian の既存のエントリをコピーしてください。 注意: Makefiles では、TABS と ホワイトスペースが混在します。かならず他のエントリは正確にコピーしてください。

Then type "make" in dom/ to build the interface. If all goes well, a file nsIDOMFabian.h should be in dom/public/idl/html/_xpidlgen/, and it should contain the C++ code for our interface. From my own experience unfortunately it sometimes necessary to build "distclean" before it works.

次にインターフェイスをビルドするために dom/ へ "make" とタイプしてください。すべてうまく行けば、 nsIDOMFabian.h ファイルが dom/public/idl/html/_xpidlgen/ にあり、インターフェイスに対して C++ コードを保持しているはずです。私の経験ではインターフェイスを機能させる前に、残念ながら "distclean" をビルドしなければならないことがあります。

See you tomorrow! (^-^)/~~~~

Mozilla DOM Hacking Guide: Introduction to XPCOM12

ある映画で見たシーン：インドを夜行列車で旅する主人公、失踪した友人を探して欧州（多分英国）からインドへはるばるやって来た。窓の外は夜の帳。主人公の顔が窓に映える。そこに流れる映画音楽：ベートーベンの弦楽四重奏7番の第3楽章。瞑想的な音楽が主人公の内面の旅に趣を添える。

映画の名前も監督の名前も忘れてしまったが、音楽とそれが使われたシーンは鮮明に憶えている。この曲は冬の夜に仕事部屋で聴くのにふさわしい。哲学的で暖かい。

音楽は容易に記憶に結びつく。ヨハン・シュトラウスの”美しき青きドナウ”を聴くと多くの人が宇宙飛行士の遊泳のシーンを思い浮かべるかもしれない。音のない宇宙遊泳のシーンに、華やかなワルツが流れるその意外な効果。ウィーンフィルのニューイヤーコンサートでこの曲を聴いていつも思い浮かぶのは、宇宙遊泳のシーンなのだ。
----------------------------------------------------------------------------

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

The syntax of XPIDL is straightforward:

#include "domstubs.idl";

[scriptable, uuid(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)]
interface nsIDOMFabian : nsISupports
{
void fabian();
readonly attribute boolean neat;
};


XPIDL の構文は簡単です:

#include "domstubs.idl";

[scriptable, uuid(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)]
interface nsIDOMFabian : nsISupports
{
void fabian();
readonly attribute boolean neat;
};


This is the definition of the nsIDOMFabian interface. The uuid of the interface is a unique identifier. Every interface needs one. You can generate ^*1them using guidgen on windows, or by issuing the command "mozbot uuid" in #mozilla on irc.mozilla.org.


これが nsIDOMFabian インターフェイスの定義です。インターフェイスの uuid は一意の識別子であり、すべてのインターフェイスに 1 つ必要です。ウインドウで guidgen を使うか、また irc.mozilla.org の #mozilla で "mozbot uuid" コマンドを発行して uuid を生成できます。
^*1→正しくは"it = an unique identifier"と単数の代名詞となるべき？

At compile-time, the XPIDL compiler will turn this interface definition into real C++ code, a header file that will contain the pure abstract class. This class will look like this:

#define NS_IDOMFABIAN_IID
{0xxxxxxxxx, 0xxxxx, 0xxxxx,
{ 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx }}

class nsIDOMFabian : public nsISupports {
public:

NS_IMETHOD Fabian(void) = 0;
NS_IMETHOD GetNeat(PRBool *aNeat) = 0;

};

#define NS_DECL_NSIDOMFABIAN
#define NS_FORWARD_NSIDOMFABIAN(_to)
#define NS_FORWARD_SAFE_NSIDOMFABIAN(_to)


コンパイル時に、XPIDL コンパイラはこのインターフェイスの定義を実際の C++ コードに変換しますが、これは純粋な抽象クラスを備えたヘッダファイルです。このクラスは以下のようになっています:

#define NS_IDOMFABIAN_IID
{0xxxxxxxxx, 0xxxxx, 0xxxxx,
{ 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx }}

class nsIDOMFabian : public nsISupports {
public:

NS_IMETHOD Fabian(void) = 0;
NS_IMETHOD GetNeat(PRBool *aNeat) = 0;

};

#define NS_DECL_NSIDOMFABIAN
#define NS_FORWARD_NSIDOMFABIAN(_to)
#define NS_FORWARD_SAFE_NSIDOMFABIAN(_to)


As we can see, the auto-generated header file contains the IID of our interface, and a "pure abstract class" is correctly defined. The XPIDL compiler turns the IDL methods and attributes into C++ functions according to the following rules:

見て分かるとおり、自動生成のヘッダは私たちのインターフェイスの IID を備えており、”純粋な抽象クラス”は正しく定義されます。XPIDL コンパイラは IDL メソッドと属性を以下のルールに従って C++ の関数へ変換します:

The methods of the interface keep the same name in C++. However in IDL we have to use the so-called "interCaps" model. That means that the first letter is lower-cased, and the other letters that begin a new word are upper-cased. For example, in IDL we'd write getElementById, which in C++ would be translated to GetElementById.

インターフェイスのメソッドは C++ でも同じ名前を保持します。しかし IDL ではいわゆる "interCaps" モデルを使用しなければなりません。つまり最初の文字は小文字になり、そのあとの新しい単語の最初の文字は大文字になります。たとえば、IDL では getElementById と書くので、C++ では　GetElementById に翻訳されることになります。

NS_IMETHOD is a macro that basically means "virtual nsresult". The argument list and return type are turned into correct C++ types according to rules not described here.

NS_IMETHOD は基本的に "virtual nsresult" を意味するマクロです。ここでは解説していませんがルールに従って、引数のリストと戻り値の型は正しい C++ の型へ変換されます。

The attributes of the interface become two functions: a getter, and a setter. In our example, since the attribute is declared as read-only, only a getter is defined: GetNeat. The argument is a pointer to an object of type PRBool, automatically generated by XPIDL. Clever uh. Note that the same interCaps model applies to IDL attributes as well.

インターフェイスの属性は 2 つの関数になります: getter と setter です。私たちの例では、属性は read-only で宣言されるので、getter だけが定義されます: GetNeat です。引数は自動的に XPIDL によって生成される PRBool 型のオブジェクトへのポインタです。賢いですね。同じ interCaps のモデルが同様に IDL の属性へ適用されることに注意してください。

The three macros are explained in detail in Section 1.E.d. The next step is to build our new interface.

1.E.d で 3 つのマクロが詳細に解説されます。次のステップは新しいインターフェイスをビルドすることです。

これで、XPIDL がどのようにインターフェイス定義を支援するかについて解説を終わります。
See you tomorrow! (^-^)/~~~~