- HMDT archive-
September, 2003

オブジェクト指向の言語比較論から、Chain of Responcibility の C++ の実装のページを更新したぜ！はじめの C++ の実装は、半分意図的に、かなり単純なものにしておいたんだよ。その理由は、いろいろ手を加えても、本質的にあまり変わりがないだろう、と思っていたから。たとえばメンバ関数ポインタを利用しても、動的に変更がきかないっていう C++ の本質的な特徴は変わらないだろうし。 だけど、メールをやり取りする中、かなり気合いの入った実装をいただいたんで、修正、追加することにした。C++ でもここまでできますよ、と。ただ、う〜む、ちょっとやり過ぎかなという気もしないでもない。

掲示板で教えていただきましたが、"with" loss of generality さんが、Chain of Responsibility の C++ での実装を公開しています。うれしいことです。 こちらでは、リクエストをテンプレートを使って、1 つ 1 つに対応するクラスを作ることで、問題解決しているようで。確かに解決されるけど、リクエストを増やすたびにクラスが必要になる、っていう至極もっともな疑問が提示されています。

メッセージ送信の比較に、NewtonScript と AppleScript を追加したよ。 NewtonScript の例を書いていただいた GUNE（鵺）さん、ありがとうございました。そして、AppleScript を書いていただいた、かりやんさん、遅くなってほんっとうにすいませんでした！！！すいません、見落としていました（泣。これからも、お願いします。あ、KEdit 使っています。

ここ最近、ずっとやってきたメッセージ送信の比較とデザインパターンの比較を、とりあえず 1 つのコーナーにまとめたよ。名前はどうしたもんかなー、と考えたけど、そのものずばりで少し挑発的に「オブジェクト指向の言語比較論」ってことにしたぜ！ 内容や実装について、いろいろ掲示板の書き込みやメールをいただいてますけど、必ず反映させるのでもう少し待ってて下さい。慣れていない言語が多いんで、おいつくの大変なんです。

きのう、体調不良で倒れていたら（正確には二日酔い）、掲示板が怒濤の勢いで進展しているし。キャッチアップするだけで、精一杯だでよ〜。 そんなみなさんのご尽力のおかげで、Chain of Responsibility の実装例が一気に増えました。ありがとうございました。Objective-C に加えて、C++、Smalltalk、Self、NewtonScript（おぉっ？！）が追加されたぜ！ いや面白い。ほんと面白い。各言語の特徴がくっきりと出て、利点がとっても分かりやすい。ぜひ、食わず嫌いせずに見てみて！ 追記）Java を追加したっす。

オブジェクト指向言語の比較、そろそろ新しい批判が出てきました。『なるほど、言語の違いは分かった。で、それがアプリケーションを作るときに何がうれしいのか？』 そんな批判に答えるために、具体的なアプリケーションの実装の比較をしてみようと思うぜ！お題をどうするべきか、悩んだ結果、GoF のデザインパターンでやってみることにした。理由は、広く知られているから。デザインパターン自体の有用性はさておくとして、あくまでも比較のための叩き台としてね。 まずは、Chain of Responsibility でやってみる。最初の試しとして、Objective-C での実装を書いてみた。なぜこのパターンからやるかって？それはもちろん、Cocoa には responder chain があるからな。得意技だぜ！実際、メッセージ送信の利点をうまく使えてると思う。このあと、C++ と Java での実装を加えてみるよ。 いまのうちに言っておくけど、デザインパターンはそんなに詳しくない。勘違いがあったら、がんがん指摘ください。あんまりひどいようだったら、すぐひっこめるかも。

最近こればっかりのオブジェクト指向言語のメッセージ送信の比較、きょうは Perl と Self を追加したぜ！Perl は terra さんに、Self は sumim さんに書いていただきました。ありがとうございました。これで 8 つか。にぎやかになったなー。

Mac OS X 10.2.8 がリリースされたことを受けて、ひっさびさに Safari Developer News を更新。さすがに Safari の開発ネタも減ってきたよなぁ。Safari Developer News は、もうニュースサイトとしての機能をほぼやめているので、ちょっと位置づけを変更しないと。

オブジェクト指向言語のメッセージ送信の比較に Ruby を追加したよ。GNUE（鵺）さんに書いていただきました。ありがとうございました。

たまには Mac に関係ないネタを。Hot Wired によると、アメリカの銀行の ATM がウィンドウズに移行するんだそうな。 これで思い出したんだけど、アメリカの空港はけっこうウィンドウズを使っている。なんで分かるかっていうと、空港に行くと、出発と到着のフライトを表示しているモニタがあるでしょ。あれが、しょっちゅうブルー・スクリーンになっているのだ。一目瞭然でウィンドウズと分かるぜ（笑）。実際のところはどうだか知らないけど、体感的には、もういたるところで止まっている。一回空港に行けば、必ずブルー・スクリーンを見かけるぐらい。空港のシステムがこんなので飛行機だいじょうぶなのかよ、って心配になるけど、そこは世界でいちばん大ざっぱなアメリカ人。まったく気にしないのだ。 ただ、一度まいったことがある。飛行機で日帰りの出張に行ったんだけど、帰ろうと思ったら飛行機が delayed になっている。遅れるってこと。はじめは 30 分の遅れだったんだけど、1 時間になり 2 時間になってもまだ出ない。聞いてみると、どうも到着地の空港がシステムをウィンドウに入れ替えた初日で、見事に止まったんだそうな（笑）。期待通りだ！そのあと 4 時間待たされて、しょうがないなホテルの交渉をするか、と思っていたところで乗れた。結局それが最終便になったそうな。スチュワーデスさんが「あなたちはラッキーね」って言ってたけど、おいこら、お前らのせいだろ。 というわけで、もし銀行の ATM がウィンドウズになったら、止まる。絶対止まる。でもアメリカ人、そういうの気にしないのかもしれない。

オブジェクト指向言語のメッセージ送信の比較をちょこっと更新。あと、メソッドの拡張を追加。

オブジェクト指向言語の比較は、このままもっと広げていきたい気もする。継承の比較とか、カプセル化の比較とか。でも、難しいー！！それぞれの言語を理解するのは、まぁできる。だけど、それをどういう切り口でまとめるか、っていうのが大変重要。複数の言語のメタ概念を取り出すようなものか。とってもタフ。たぶん、ギブアップ。

オブジェクト指向言語のメッセージ送信の比較、掲示板でいろいろ突っ込みをもらいました。ありがとうございました。 とにかく言えるのは、異なる言語を比較するのは難しい！ま、やる前から分かっていたことだけど。ある言語の概念で比較の項目を決めると、別の言語ではうまく当てはまらないし。どうにもこうにも収まりが悪いので、sumim さんのアドバイスをもとに、構成を変更しました。メッセージ送信については、 通常のメッセージ送信 実行時にメッセージを取得する送信 メソッドオブジェクトに対する、起動メッセージの送信 メソッドの実装を利用した呼び出し っていう項目にしました。細かい定義はページの方でどうぞ。メソッドの追加や置換については、明日別のページでまとめます。考えたら疲れたよ、ぷひー。

あと、比較対象の言語として Dylan を加えました。掲示板で説明してくれた 2 さん（でいいですか？）、ありがとうございます。Dylan は名前しか知らなかったんですけど、ふーむ、こういうものなのか。メッセージ送信だけで見ると、それほど自由度があるわけでもないのか？

きのうぽろっと、Scheme という名前を出したら、掲示板でがんがん突っ込みをいただきました。いわく、Scheme は言語仕様としてはオブジェクト指向を実現しているわけではない、と。知ったかぶりをして、恥をかくという一例ですね。kogule さん、ama さん、ありがとうございました。

きのう書いたC++ と Java と Objective-C のメッセージ送信の比較だけど、Smalltalk を追加したぜ！当方 Smalltalk は分からないので、sumim さんに書いていただきました。感謝！ あとは、Ruby と Scheme かな。Apple ファンとしては、Dylan もかな。お願い、誰か！

しつこく、メッセージ送信の話を。面白そうなんで、C++ と Java と Objective-C のメッセージ送信の比較をしてみた。かなり Objective-C よりになってしまったと思うので、がんがん突っ込んでくれ。 「メッセージ送信」っていうとこれだけのことが含まれるんだけど、これを「関数呼び出し」って呼ぶだけで伝わるかなぁ。

おぉ、ワイアレスマウスが！欲しい。これ欲しい。やっと iMac の Bluetooth が生かされるときがきた。

Panther はしばらくは出ないわけか。Xcode を使える日は、まだ先。

きのうの続きで「疑り深いあなたのためのオブジェクト指向再入門」への突っ込み。「皆様からのご意見」が公開されていました。HMDT への返事もあって、ありがとうございます。 「こう考えると、Objective-Cでは、関数(メソッド)を見つける部分の手続きは異なるけれど、見つけた後に行うことは結局「関数呼び出し」であるように思うのですが、どうでしょうか。」 そうそう。Objective-C では、メッセージは「メソッド検索＋実装の関数の呼び出し」ということで、明確に関数呼び出しとは違いますよね。え、そういうつもりじゃなかったって？ ま、結果的に関数呼び出すんだけど、それはランタイムの中をのぞけばみんなそうなわけで。それは「C をコンパイルすればアセンブリになるんだから、関数呼び出しはアドレスジャンプと変わらない」と考えるのと同じくらい実りがないです。 Objective-C での関数呼び出しに対するメソッドの利点は、コンパイル時にメソッドの実装を知る必要がない、つーかメソッドの名前すら知らなくてもいい、というとこですか。 「ところで、通常、誰かに「メッセージ」を送って何かやってもらうとき、相手の作業が終了するのをじっと待つ必要は 必ずしもないはずです。自分は自分で、別の仕事をやっていてもいい。「こんな説明を読むと、まるで各オブジェクトにそれぞれプロセスが割り当てられていて、プロセス間通信で動作するかのように思えますが」と書いたのは、そういう誤解を招きかねない、という意味で書きました。」 これが論点なら、「「メッセージ」をプロセス間通信と勘違いしているやつらには、きちんと違いを教えてやるべし。ただし、C++ ではただの関数呼び出しみたいになっちゃうけど。」って書くのがいいのでは？ 他の方からの意見も届いているみたいですけど、なんか多くは「オブジェクト指向を C++、Java の観点だけで捉えるな」っていっているような気がするんです。Smalltalk だの Objective-C だの Ruby だの Pyhton だのに目を向ければ、もっと便利で面白い世界があるわけですし。

HMDT 本の正誤表を更新。ちょこちょこと更新。

K. Maebashi's home page で、「疑り深いあなたのためのオブジェクト指向再入門」という記事が公開されていた。タイトルがそのまま内容を現している訳で、読んでみた。まだ序盤だけど、おもしろいし、分かりやすい。分かりやすいが故に、突っ込みたくてうずうずしてしまったので、ここで突っ込んでみよう。 「オブジェクト指向の入門書では、「謎のたとえ話」から始まるものが多いように思います。（なぜわからなくなってしまうのか？より）」 その通りだ！おれもそう思うよ。ほんと、「哺乳類オブジェクト」や「乗り物オブジェクト」から始めるのはやめようよ。これで説明されると、ぜんぜん具体的なイメージがつかめないし、細かく突っ込もうとすると「これは例ですから深く考えないで下さい」とか言われるし。うきー！ ちなみに HMDT 本では、オブジェクトの説明の例としては、ウィンドウ上に出てくる「ボタンオブジェクト」を使っています。これなら日ごろ良く使っているものだし、実際にプログラミングで使われているオブジェクトだから、分かりやすいと思うんだけどなー。 「オブジェクト指向をわかりにくいものにしている最大の要因として、「メッセージ」という言葉が挙げられます。... 「メッセージ送出」と呼ばれているのは、 実のところ単なる関数呼び出しです。 こんなものに「メッセージ」などという大仰な名前を付けていることが、結果としてオブジェクト指向の理解を妨げていると思います。（なぜわからなくなってしまうのか？より）」 これは同意できない。C++ や Java の説明ならこれでもいいでしょう。だけど、Objective-C みたいに、動的束縛を利用する言語では、関数呼び出しとメッセージ送信は明確に区別する必要があるから。 では、動的束縛とオブジェクト指向との関係は？立場にもよるんだろうけど、必須ではないけれど、とても重要なものの一つ、でしょう。これがあるとないとでは、オブジェクトというものの捉え方ががらり、と変わってくるからね。 ま、一番最初に「言語としてはJavaを使用します。」と断ってあるからいいのかもしれないけど。でも「メッセージ＝関数呼び出し」は、オブジェクト指向の可能性をとても狭くしてしまう。だから、まとめにある「「メッセージ」なんて言葉を嬉しがって使ってる奴はたいてい「知ったか」野郎である。」は、やめといた方がいいんじゃない？ 「オセロを例に考える」 オブジェクト指向のマルチプルインスタンスの例として、オセロの盤面オブジェクトを出しているけど、いやー、これだったらおれも盤面をグローバル変数にするか、singleton なオブジェクトにするなぁ。複数のインスタンスを作る状況として、オセロのネットワーク対戦をやるなら盤面が複数必要でしょ、って言ってるけど、ちょっと強引。複数プロセスを立ち上げるほうが自然な感じがしたりして。 例にちゃちゃを入れるのは本質的ではないと思うけど、わざわざ「現実のプログラミングに即した例題を使用するべきでしょう。」と書いているので、もう少し適切な例だったらよかったのに。

再び XSLT ネタ。いろいろ XSLT でプログラム書いているんだけど、どーもうまくいかないんだよ。あるアルゴリズムを考えても、それが記述できないことが多い。どうなってんの？と思ってたら、XSLT では出来ないことというページが。 これによると、include の条件選択もできないし、呼び出すテンプレートの名前を動的に変更することも出来ない。ぐはぁっ。つまり、ガチガチに静的な言語な訳ね。これならたしかに、プログラミング言語と呼ぶより、スタイルシートって呼んだ方がしっくりくるなぁ。 これじゃ、別の言語で動的にスタイルシートを作るしかないのか。つーか、もともとそういう思想で設計されたのか。うーむ、これだったら別の言語を使うか、自分でがしがしと Objective-C などでプログラムを書いた方がいいような気がするぞ。

掲示板の方で、透明ウィンドウの話題が出ていたので、Cocoa 1001 にまとめてみた。ひっさびさの、Cocoa 1001 だな。 - 半透明ウィンドウを表示する - 透明ウィンドウを使う ここでは、Dock の、あのアイテムを削除したときに出る煙を、実現するためのアプリケーションを紹介しているぜ。

Apple より、新しい iPod の発表が。がーん、がーん、、、 実は、この間の土曜日に iPod を買ってきてしまっていたのでした。15G モデル。それが月曜日に新モデルの発表。価格据え置きで、15G は 20G に。はぅ。だれも iPod の新型の噂なんか、していなかったのに。 ま、どーせハードディスクあまりまくっているから、5G 増えたところであまり関係ないんだけど（負け惜しみ）。ふんっ。

ソフトウェア・アップデートより、「Java 1.4.1 アップデート 1」が配付されている。インストールすると、Java Runtimer Environment のバージョンが 1.4.1_01-39 から 1.4.1_01-69.1 へ。HotSpot は 1.4.1_01-14 から 1.4.1_01-24 へ。なんとも小刻みなバージョン番号。 しかし、その効果は抜群。今回はとくに GUI 周りの描画がアップデートされたらしくて、体感スピードが全然違うぜ！いままで使い物にならなかった Oxygen も、これなら使える。テキストエディタのバグもとれたみたいだし。始めから、このレベレで出してくれよぉー。

Think Secret が Panther developer notes っていう記事を出してた。Apple から出ている Panther の開発者向け情報から、未来のヒントを探ろう、というものだ。ふ〜ん、と思いながら眺めていたら、見慣れない単語が 1 つ。「vImage」ってのがある。これは、なに？ Think Secret の説明では、Panther の画像処理のデモで使われた、フォルダアクションにつけて、画像のリサイズや変換を行うためのもの、となっている。もう少し調べてみた。vImage は、Accelerate.framework っていうフレームワークの一部らしい。このフレームワークには、vImage と Velocity Engine のための vecLib.framework があるようだ。どうも、ハードウェア依存の最適化をラップするためのフレームワークのようだ。 で、vImage の API では、画像のビットマップデータを直接いじれるようだ。画像のフォーマットの変換、畳み込み、アフィン変換、ヒストグラムの算出、エロージョンとダイレーションとかの処理ができる、と。ハードウェアを利用した画像処理を、比較的ハイレベルの API で触れる、ということかな。どうやら AppleScript からもいじれるようだし。新しい Preview も、これを使っているのかな？ これはちょっと、面白いおもちゃになるかも。

Apple が Optimizing for the Power Mac G5 という文書を公開していた。G5 プロセッサ用の最適化を解説した文書だ。ざっと読んで、要約を作ってみた。 Power Mac G5 は、ただの G4 の速い版、というわけではない。速いだけではなくて、G5 プロセッサは 64-bit だし、U3 システムコントローラも速いし、400 MHz の 128-bit DDR SDRAM も速いし、1 GHz のフロントサイドバスも速いし、OS も 64-bit を前提に設計されている。 Xcode を使え。gcc 3.3 コンパイラが使われていて、これには G5 用のコンパイラフラグが追加されている。また、最適化をするには、Xcode に含まれている 2 つの解析ツールを使うといい。1 つは、Sampler。もう 1 つは Shark で、CHUD に含まれている。これらについては、TN 2086: Tuning for the G5: A Practical Guide を見てくれ。 アプリケーションが、ベクトル演算、行列演算、信号処理とかをやっているなら、vecLib を使って Velocity Engine を使うべきだろう。これについては、Velocity Engine のページを見てくれ。 最適化を、段階ごとに解説しよう。G5 のもっと詳しい最適化については、TN 2086: Tuning for the G5: A Practical Guide や、TN 2087: PowerPC G5 Performance Primer を見てくれ。 Level 0 -O3 フラグを使って、再コンパイルする。ソースコードを調べて、データをまとめて一括処理するようにする。データの型の変換を最小限に押さえる。 Level 1 G5 用のフラグを使って、再コンパイルする。Sampler を使って、ホットスポットを探す。平方根を使っているなら、G5 のビルトインの平方根命令を使うようにする。 Level 2 Shark を使って、ホットスポットを探す。32-bit align アドレスにする。G3、G4 用の最適化ルーチンがあるなら、それを G5 用に書き直す。 Level 3 G5 のデュアル 64-bit FPU、デュアル 64-bit 整数ユニット、デュアル load/store ユニットを使うようにする。ビルトイン　Velocity Engine を使うようにする。 一言でいうと、Xcode を使って、G5 用にコードを書いてコンパイルしろ、ということか。当たり前だけどね。途中で紹介されている、TN 2086 や TN 2087 もなかなか面白いです。

前、Safari で文章の途中で文字化けする現象について問題にしていたよね。多バイトの文字が、途中で切られてしまうために発生するやつ。 某 ML によると、この問題を多バイトの「泣き別れ」と呼ぶらしい。おぉ、そんな呼び方があったのか。「泣き別れ　マルチバイト」で検索すると、ほんとだ見つかる。他の呼び方もありそうだな。

IBM が Mac OS X 用の C、C++ コンパイラである XL C/C++ for Mac OS X のベータ版を公開しているらしい。G5 用だそうな。 mkino は、G5 持っていなくて、Objective-C でプログラム書いていて、数値計算ほとんどしないので、すぐに役に立つことはないけど、いちおう覚えておこう。

相変わらず、過去コンテンツのメンテナンスモード中。やってもやっても終わんない。多すぎるんだよな、はっきりいって。書きかけて、ほったらかしてあるのも多数だし。いっそのこと、ばっさり切り捨ててしまいたい、、、

昨日の夜は、ずっとネットワーク不調。今度は、ISP 側の問題だったようだ。もう、いやっ。 関係ないけど、DVD プレイヤーも不調。ディスクが認識されない。10 回ぐらい出し入れをすると、たまに見れる。もう、いやっ。

なんか、最近ただの日記になってるな。

掲示板、絶不調すぎて怒られてしまったので、移転したっす。自宅サーバはやめました。いつか、ネットワーク環境を整備して、再トライします。 新しい掲示板はこちら。ではでは。

掲示板の過去ログ、編集したので公開するよ！こちらからどうぞ。見返してみると、自宅サーバは 6/11 からスタートしていた。3 か月足らずで終了。短っ。まぁ、Mac 付けっぱなしにしてると、けっこうファンの音とか気になってたから、ちょうどよかったかも。次こそは、部屋の環境も整えて、再び、、、！

WILLBE6.org さんが、DSSL という XML ベースの自動組版システムの講座を開始している。 「この講座は、"近頃は手当たり次第 XML にしまっくてるぜ" とか、"うちのサイト、XML + XSLT にしたんですよ" という人達のため」とのこと。あ、うちそれ、うちそれ！