JavaScript 周りをもう一回確認しなきゃな

class ベース OO をマネっこしてるフレームワークは class 名というかコンストラクタというか、それを取得できなくなるよね?と不安になり、確認してみた1。あと、コンストラクタや prototype プロパティへあれこれ追加する記法が変わっちゃうとドキュメンテーションツールが対応できなくなるんじゃね?と思い、それを確認…しなきゃと思っているところ。(つまりまだ確認していない。)

挙げたのは小さめで目に留まっているものだけ。別にフレームワークを網羅するつもりはないし、大きいものは扱いに困りそうで敬遠してるところ。

class名

prototype(1.4)
constructor も instanceof も意図通り動作せず
jQuery(1.0.2)
独自の class 構文はない
mootools(rev.64)
constructor は意図通り取得できないが、instanceof での確認は可能

こうして見ると Web に特化しちゃうなら jQuery もアリかなと思わなくもない。mootools は全体の構造も丁寧に整理されている感じで好感が持てる。

prototype は最初のインパクトはすごかったが、インスパイアされた後出しのものが結構いいし、使うなら上のような問題がないものの方が嬉しいな。まぁ prototype が現状ではいちばん情報が豊富っぽいんだけど。

ドキュメンテーション

class の構造やツリーをドキュメント生成ツールが正しく認識できなくなるとドキュメントの自動生成ができなくなり、結果、ドキュメントのないコードだけが残り、「最初に書いたもん勝ち」というありがちな状況を生みそう。ということでドキュメント生成ツールとの相性を確認しなきゃな、と思っている。

今回、気になって調べたら Natural Docs という、これまた Perl で書かれたツールがあるみたいなので、それの動作も確認できたらいいなと思っている。

jsDoc × prototype
jsDoc × mootools
Natural Docs × prototype
Natural Docs × mootools

jQuery は独自の class 構文がないのでドキュメント生成ツールの対応を考える必要はたぶんないと思う。

Ajaxian >> Natural Docs: Better Javascript Doc によると、DoJo と Natural Docs の相性は悪くないのかな?

  1. そんなもん分かんなくたってメソッドがあったら動けばいいじゃないという考え方はもちろんアリ。 

More