著作一覧 |
1994年頃、つまり僕が本格的にコンポーネントの開発をする必要が出た頃ですら、すでに巨大極まりないものだった。
確かにMFCを使えばそこそこのOCXが作れるわけだが、それはIDispatch以外のVTblを使えないから、VBからはペタポトできてもC++からはえらく使いにくいものだった。
そこで、COMの永遠のベータ仕様書を読み、TechNoteに隅々まで目を通してMFCのIUnknwonをMap(ユーザー定義関数ポインタテーブル用マクロ)へマッピングする方法を調べて、そしてデュアルインターフェイスを作り、するとVB4が単なるコンポーネントについてはデュアルインターフェイスを見つけるもののOCXについてはインターフェイスが見つからない状態になることがわかり、しょうがないのでODLにDispInterfaceも実装しQueryInterfaceをオーバーライドして振り分けを実装し、するとIPropertyBagの取り方に問題が出てきて……というようなことが必要だった。
回り道だ。
というようなことを思い出すASP.NETのなんでもありあり(しかしこちらを立てるとあちらは立たない)アプローチ。ポストバックするのか、Transferするのか、クライアントコールバックするのか、Redirectで十分なのか、5種類あるクライアントサイド状態管理のどれを使うのか、それとも3種類あるサーバーサイド状態管理のどれを使うのか(これは明確に役割が分かれているから良いのか。とすると4種類あるセッション状態管理のどれを使うのかあたりにしておくか)、全部知らなければ確実に痛い思いをする可能性はあり、かつ何も知らなくてもそれなりにできる。ASP.NET1.0を知らない人間がASP.NET2.0をはたして正しく使えるのか?
別に正しく使う必要はないのだとすれば、そしてそのアプローチはコスト的にはそれなりに正当ではあるのだが、するとASP.NETが持つたくさんの機能はいったいなんのためなんだろうか? もちろん、MSのASP.NET開発チームのためなのだろう。でも、回り回ってオレのためとも言える。
どうしようかなぁ。
あらためて読むとすごくおもしろい。というか、ASP.NETに対する知識と必要性が最初読んだときと今ではえらく異なるからな。
.NETが、COMよりも格段におもしろいのは、それがVMだからでもクラスライブラリが完備しつつあるからでもないんじゃないかという気がしてくる。というか、そういうことは実用的ではあってもおもしろい理由ではない。
COMは結局はVTblだし、つまりはC++だ。そして、C++は実行時に参照できるものはほとんどない。多分。
// test.cpp #include <fstream> int main(int argc, char* argv[]) { std::ofstream o; o.open("temp.cpp"); o << "#include <iostream>\n"; o << "int main(int argc, char* argv[]) {\n"; for (int i = 1; i < argc; i++) { o << argv[i] << '\n'; } o << "}\n"; o.close(); std::string s("cl "); s += "temp.cpp"; system(s.c_str()); return system(".\\temp.exe"); }実行する。
C:\temp\cpl>test "return 3 + 4 * 12;" Microsoft(R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. temp.cpp (……すごくたくさんのアンワインドセマンティクスに関する警告……) /out:temp.exe temp.obj C:\temp\cpl>echo %ERRORLEVEL% 51 C:\temp\cpl>当然の結果だ。
というわけで、別に普通にできることなのに、なぜC++では実行時にコンパイルしないでこれまで来たのか、そしてなぜ、ここ最近になってASP.NETとかは実行時にコンパイルするようになったのか?
CLRが仮想マシンだということはこのさい全然関係ない。
なんなら、上のC++プログラムをバーチャルPCの上で実行したって良いわけだし。仮想マシンでAPIが完全無欠なWin32API。
ヘッダファイルの参照の仕組みとプリプロセッサ。とはいっても実行時コンパイルしてすぐ実行というのに、この2つが制約になるこたないだろう。
速度かな?
でも、JSPのおそーいおそーい初回実行について知っていれば、あるいは最近のマシンは結構早いのに助けられてるからだろうけど、ASP.NETの遅い初回実行を知っていれば、そういうものか、で済ませられる程度の話だ。
必要ならば、最初に一発ダミーの要求を打ってやるというような手段もある。
上の例(test.cpp)は、動的コード(ここでは引数で指定するコード)に対して別段マクロは提供していないが(iostreamの参照だけを認めている)、便利なマクロを吐き出すソースコード上に定義することは可能だ。
その場合、動的コードはC++とは異なる書き方ができる。
LISP最強伝説にマクロという言葉が頻出するのはそういうことだ。
だって、不等号がたくさん出てくるから、tDiaryを普通に使っているとやたらと実体参照が必要になって面倒なんだもん。
ASP.NETの本質は実行時コンパイルにある。
もちろん、ふつうはテストをするからそれで構わないのだ。
でも、ってことは、すでに静的なコンパイルがあるから動的でアジャイルな言語(Rubyとか)ではなく、.NETを選びますとか、Java(JSP式言語について、どう処理されるか想像すれば良い)を選びますとか言えるのだろうか?
もちろん、言えない。恥知らずか無知でない限り。
それでも、Javaの場合にはまだビジネスオブジェクトとUIの切り離しがスタンダードだから、式言語程度でしか利用しないのなら知らなかったふりはできるだろう。
でも、ASP.NETの場合、App_Codeはあるけれど、コードビハインドのPage派生クラスにロジックを埋めることは多いんじゃないかな? (どうなんだろうね)
IISとの連動とかは、十二分に理由になるとは思うけど、つまりはプログラミング環境は選択の理由には、ほとんどならない。
つまり、テストは重要で、しかももっとも脆いのはUIの部分だ。
ここで、ASP.NETの場合、ユーザー定義サーバーコントロールがDIベースだというのが意味を持つ。
DIといえばテスト。
と、mumurikさんのブログを巡る旅の1つのコースが閉じる。
こいつらのテストってどうやるんだ?
というか、以前TagLib書いたとき何かやったような記憶があるが、作ったのは山ほどあるうちの2クラスだけだから全然覚えてないな。
というか、TagLibって良く考えなくてもうまい仕組みだったような気がしてきたぞ。
ジェズイットを見習え |
そのうちControlBuilderとReadマクロを比較して普通のJavaユーザーの上を行く話を書こうと思いつつ最近はIronPythonに流れてしまっています:D