Kanasan.JS Prototype.js CodeReading #5: Days on the Moon

Kanasan.JS の Prototype.js CodeReading #5 に行ってきました (当日のチャットログ、参加者のブログ記事一覧)。対象は Prototype.js 1.6.0.2 です。ちなみに私は前回お休みしたので、前日にその分をざっとさらえての参加でした。

Element.Methods.Simulated.hasAttribute (2521 行目)

IE 7 は DOM 2 Core の Element#hasAttribute を実装してないので、その代替です。

Element.addMethods (2583 行目)

可変引数の処理を、引数の値が新かどうかで判断したり、arguments.length を見たりと一貫性がありません。増改築を繰り返してきた結果でしょうか?

findDOMClass (2625 行目)

Firefox などでは DOM HTML の各インターフェースに対応する擬似コンストラクタ関数とでもいうべきオブジェクトが実装されています。たとえば、DOM HTML では p 要素の要素ノードオブジェクトは HTMLParagraphElement インターフェースを実装することとなっていますが、Firefox では p 要素ノードオブジェクトのプロトタイプが HTMLParagraphElement コンストラクタ関数 (new 演算子は使えませんが) の prototype プロパティの値と同じオブジェクトになります。

HTMLParagraphElement;
// Firefox 3 => [object HTMLParagraphElement]
// コンストラクタ関数に相当するが、
// new 演算子を使ったオブジェクトの作成はできない

HTMLParagraphElement.prototype;
// Firefox 3 => [xpconnect wrapped native prototype]
// コンストラクタ関数に相当するので、
// 関数オブジェクトと同様に prototype プロパティを持つ

// p 要素ノードオブジェクトを作成
var p = document.createElement("p");

p.__proto__ == HTMLParagraphElement.prototype;
// Firefox 3 => true
// p 要素ノードオブジェクトのプロトタイプは
// HTMLParagraphElement.prototype と等しい

findDOMClass 関数は Element.addMethods の中で内部的に使われる関数で、この要素ノードのコンストラクタ関数 (のようなオブジェクト) を取得します。

Selector#shouldUseXPath (2706 行目)

should～というメソッド名はあまり見ないという声がありましたが、個人的には is～、does～と同様に時々見かける気がします。can～とはニュアンスが違いますし。

私が実際に使ったパターンとして、特定のメニュー項目を表示させるかどうかチェックするメソッドに shouldDisplay と名づけたことがありました。canDisplay だと「表示できるか」となって、表示しようと思えば表示できるので常に true を返しそうですが、使えないメニュー項目を表示させたところで意味がありませんからね。

Selector#compileMatcher (2724 行目)

CSS セレクタを基に、特定のノードを選択する関数を動的に作成しています。関数のソースを文字列としてつなげていき、最後に eval 関数を使って関数を生成、matcher プロパティにその関数を設定します。途中、関数のソース文字列を収めた配列も matcher プロパティに設定しているのがわかりづらいですね。この配列はローカル変数で持っておけばいいと思うのですが。

処理の流れとしては、CSS セレクタからトークンを切り出し、それに対応するソース文字列を追加していきます。たとえば、CSS セレクタが "#foo" (id が foo である要素を選択) だったときは以下のようになります。