closure を知らなかった件

今日の今日まで closure の存在を知りませんでした。ゴメンナサイ。もしかしたら今まで書いたコードの中にバグがあったかもしれません。しかしながら、インスタンス変数でない限り、 function 内で宣言した変数なんてものは月下美人のごとく一夜限りの命かと思っていましたが、そんなことはないというのは非常に奇妙に感じます。

そんなこんなで closure を知らなかった僕のような人を出来るだけ減らすために今回は closure に関して説明をしてみます。

クロージャのサンプルコードを書いてみます
---
var hoge = function(){
　　var i = 0;
　　var foo = function(){
　　　　i++;
　　　　return i;
　　};
　　return foo;
};

var bar = hoge(); // (1)
alert(bar()); // 結果：1 (2)
alert(bar()); // 結果：2 (3)
alert(bar()); // 結果：3
---
まぁこんな感じでしょう。

・　(1) で hoge の結果が bar に入ります。
・　hoge の内部で return foo となってるので foo への関数ポインタが突っ込まれます。
・　なので bar() とやると foo() とやってるのと同じことになります。
・　i=0 で宣言されてるので (2) で 1 が返るのは当たり前。
・　でもね
・　(3) で i がさらにインクリメントされます！ (当たり前じゃーんとか言う人はスルーしてね

どういうことかというと (1) でbar に hoge() の結果が突っ込まれたときに foo が定義され、同時に i も定義されています。 foo 内の i はhoge のスコープでで定義されています。i の状態がbar()が終わっても保持されているということは、つまりは foo が foo の 定義時の定義スコープを保持するわけです（やはり説明が難しいなこれ）。んで、この関数本体(foo)と定義スコープの対を「クロージャ(closure)」、ここでいう hoge を「エンクロージャ(enclosure)」と呼ぶそうです。

これって結構重要で、便利に使う方法を探すのは良いですけど、逆にバグの温床になりそうな悪寒がします。使い捨てだと思っていた関数内で宣言した変数が状態を保持するとなると、予期せぬ結果が返ったりするかもしれません。

いままでこんなこと知らなかったことにちと反省。しかしこれは奇妙だ。

objectdump.jsが便利すぎる件

Javascriptを組むときの強い味方といえばFirebugですが、僕の場合、Firebugでエラー拾え切れないときはOperaやSafariのエラーコンソールを使っております。IEはIEのバグつぶしのみ使用。IEなんてブラウザ、さっさとなくなればいいのに・・・なんて話はおいといて、PHPを組むときはprint_rやvar_dumpが便利なのでそれを利用していたりします。ただこれらはJavascriptには用意されてないので、arrayやobjectをdumpする場合は別途関数を自前で作るかどこかから拾ってくる必要があります。

最近まで ウノウラボで公開されてるprint_r を使用していましたが、別サイトで objectdump.js なるものを発見し、使ってみたところこれがなかなか完成度が高く便利でした。

まぁやってることはおそらくどちらもほぼ同じなんでしょうけど（ソース読んでないから知らん。おそらく再帰関数でゴリゴリやってるだけだと思う） objectdump.js のほうが作り込みが激しく、なかなかいい感じです。

マイ糞ソフトのActiveXObject以外ならおそらくすべてdump出来るので、一度お試しあれ。特に自分の作ったWEBアプリのwindowオブジェクトをdumpすると意外な発見があるかもしれません。「え、それってそこにつながっ・・あー・・ね。」みたいな。単純な使い方は簡単で、リファレンスもリンク先にあるので使い方は割愛します。

WEBサイトの構造を考える -その6-

さて、第６回です。ちと音楽活動に専念していてなかなかこちらが更新できてませんが、がんばっていきます。

今回は、”その２”で「 --- 具体的いうと、入力フォームで記述された記事をJSON（の予定。他のフォーマットでも可）ファイルで書き出し --- 」ということを書いた件について。

この記事を書いた時点ではprototype.jsを使ってjsonでのサーバ・クライアント間のやり取りをメインにスクリプトを組んでいたため、こういうことを書きました。でもよく考えたら今回作るのはWEBサイトです。Jsonを使う目的はデータとデザインの分離。それって何かすでに用意されてなかったっけ？っと思ったら、XMLがあるじゃないか！という話になったわけです。AjaxならぬAjasonばっかりやってるとXMLの存在を忘れがちになってしまうのが問題ですね。

ということで現在XMLとXSLTをJavascriptを使ってAjax的に出来るライブラリを作成中です。物自体はjQueryのプラグイン・・・というかjQueryに依存したものになりそうです。
おおよそのところは完成(とりあえずの動作は出来た、後はエラー処理などの実装のみ)してるので、近日ソース公開と行きたいですね。

で、大まかなロジックは
・　XMLHttpRequest(jQueryを使用)でXMLとXSLを取得
・　JavascriptでのXSLTで生成したHTMLを任意のタグへ突っ込む
単純な話ですね。

普通のXSLTだとXML自体に書かれたXSLを読み込んで勝手にXSLTがあたるわけですが、Ajax的に操作を行う場合は自分でスクリプト上で当ててやらないといけない点が異なります。ただしおおよそブラウザのコンパイルされた機能を使うのでめちゃくちゃ高速です。PHPのSmartyなどのテンプレートエンジンよりはるかに速い。また、逆に自分でやれるだけに自由度が高まります。XML、XSL、CSSすべてあと取りさくさくなのでフレキシブルでダイナミックなサイトの構築が可能になりますね。

Javascriptで処理するだけにクライアントのリソースを多少消費しますが、高速なサイト作りで重要なのはサーバのリソースを出来るだけ使わないようにすることで、今日日のクライアントPCなんて一部の変態を除けばあまりまくってるんですから、どんどんクライアントのリソースを消費しちゃっていこうと思います（VM立ち上げてコンパイルしながらニコニコ見てるとかいう変態さんゴメンナサイ）

ちなみにMySQL5.1からはクエリの結果を直接XMLで出力できるそうなので、より高速なWEBインターフェイスを構築することが可能になるようです。また、amazonのようにXMLDBに乗り換えるというのもひとつの手かと。ただXMLDBは直接テキストファイル（XML）をいじる構造なのだと思うので、既存のDBと比べて書き込み性能がどれくらい落ちるのかが気になるところです。

1998年にw3cから勧告された割にはRSS以外ではWEBにはあまり用いられない（他の用途では結構使われている）XMLでありますが、いよいよWEBにも多用する時代が来たのかもしれません（ぇ、もうばりばり使ってるよ？って話があったらゴメンナサイ）

国尾衛のニコニコ動画アップロード情報

「ショパン：：幻想即興曲」だそうで。あちこちミスってやがる。