このサイトを閲覧している環境にインストールされているフォントに合わせて、 印刷用のフォントセットを選択するようなスクリプトと CSS のセットを仕込んでしまいました。 優先順位付きで定義してある複数のフォントセットに対して、 必要なフォントがインストールされているかどうかを判定していき、 はじめて必要フォントがすべて検出されたセットを適用します。 なおこの処理はサイト初回訪問時に一度だけ走らせて結果を cookie に保存し、次回以降は実行しません。 これで、どのブラウザでも明朝体で印刷されるようになったはずです。 ちなみに定義済みフォントセットは次の通りです。
インストールされているフォントの検出には Lalit Patel 氏が作った Detector クラスを使いました。 検出の原理は、ページ読み込み直後に Javascript で適当な文字列を入れた DIV 要素を作り、 これに検出したいフォントを適用することでボックス幅が変化するかどうかで判定する、 というものです。 Apache License で公開してくれているので、ありがたく使わせてもらいました。
.NET Compact Framework で原因不明のエラーが発生していたので何が悪いのかと調べたところ、
stackalloc を使うと例外が発生することが分かりました。
たまにしか使っていない機能なので修正するのは楽なのですが、
.NET Compact Framework
用にコンパイルしてもコンパイル時にエラーも警告も出ないので原因が分かるまでに時間がかかってしまいました。
ちなみにウェブを検索したところ次の URL で同じ話題が出ていますので、
私のプログラムミスではありません（笑）。
stackalloc on .net CF
サイト更新をせず、一ヶ月も放置してしまいました（苦笑）。 その間は研究の引き継ぎをしていたり、 研究室の大掃除や機材の後片付けをしていたり（今年で私の先生は退官されるので）、 PDF の仕様書とにらめっこして PDF からテキストを抽出するロジックを実装していたりで あっという間に過ぎていきました。 また、密かに進めている .NET Compact Framework でも動く C# 製テキストエディタエンジンの実装もやっていたので 更新よりもそっちに時間を使っていたり。 さらに、実は X-BOX 360 を買ってしまい、 HALO 3 に結構な時間を吸い取られているというか貢いでいるというか（苦笑）。
そんなこんなでサイト更新に関係の無いことばかりやっていたのかというと、 そうでもありません。 「C 言語でオブジェクト指向プログラミングを行う」 という記事を電車の中で「アドエス」 （Advanced Zero 3 [es]; Willcom の Windows Mobile 搭載 PHS） を使って書いていました。 ちなみにアドエスは普通の携帯電話に比べて記事を書くには良い端末です。 この記事はほぼ書き終わったので、 あと数回推敲してから公開する予定です。 早ければ明日でしょう。
ところで、Internet Explorer 8 の beta 1 を Windows Vista x64 Edition にインストールするという、 非常に「いばらな道」に入ってみました。 IE8 は、とりあえず未完成です。 とくに日本語を選択すると一部が消えてしまう妙な現象が起こったりします （選択を解除すればまた表示されるので実用上の問題にはならない）。 しかし、表示エンジンが 7 以前のもの (Trident) から一新されるという話をどこかで聞いたような気がするのですが、 どうやら本当のようです。 特に文字を選択する時の挙動が明らかに以前のエンジンとは異なっており、 従来エンジンをベースに修正を行ったにしては違いが大きすぎると感じます。 ちなみに、XPS Viewer に近い挙動と感じました。 すこし脱線すると、 Mac OS X が GUI のグラフィックを内部的に PDF（だったはず？）形式で持っているように、 Windows Vista は GUI のグラフィックを XPS (XML Paper Specification) 形式で持つという話があったように思います （うろ覚えばっかりでイケマセンね（苦笑））。 そして IE7 以前のエンジン Trident が異常なまでに柔軟な表示機能を持つこと、 さらに度重なる機能追加が行われてきたことを考えると、 おそらくソースコードは「悪夢」そのものでしょう。 ここからは個人的な推測にしか過ぎませんが、 この二点を考えると、IE のエンジンを XPS で描画を行うような新しいエンジンに変更したいと考えるのは決して不自然ではないと思います。 つまり、読み込んだ HTML を（XML として解釈してから） XSLT を使って XPS に変換するエンジンを作り、 その結果を Vista の XPS レンダリングエンジンに投げる、 というシステムが IE8 なのではないかと個人的には推測しました。 いや、まったくもって「遊び」と呼んで良いような推測ですが、 そうだとすればソフトウェア技術者としては非常に興味をそそられる話題と言えます。
あとがき。どうにも Microsoft に関する話題は否定ばかりが目につきます。 確かに否定されて当然なことばかりやっている感は否めないのですが、 否定だけでは何も新しいことは生まれません。 否定した後で、肯定もしてみて欲しいものです。 そうすれば、一つくらいは意味のある何かを得られるはずですから。 否定だけの人生は、まさに無駄です。 ・・・こんなことを書いてしまうとは、年を取ったものです（笑）。
本日購入した CD 3 枚を紹介。
とりあえず Calm の Silver Moon が非常に良いです。 FILFLA の FROLICFON もすばらしい。 Dom Mino' の Time Lapse についても同様に、すばらしい。 今回は大当たり、という感じで嬉しいです（笑）。
Java の Swing ライブラリで作った GUI を、
各種の日本製スクリーンリーダで読み上げ可能にするソフトウェア
SwingReader を公開しました。
もし興味を持たれた方は、次のリンクから専用のページへどうぞ。
SwingReader のページ
何故か私のデスクトップマシンで DRM で保護された WMV ファイルを再生すると、 どの動画プレイヤーを使っても強制終了してしまう問題が起きていました。 おぼろげな記憶ですが、wmp.dll だったか system32 フォルダ内にあるシステム共有 DLL の中で異常終了していましたので、動画デコーダか DRM のライセンス関連のライブラリに問題があったようです。 結局この問題を解決できなかったため、 Windows 2000 を再インストールしてみたところ再生できるようになったのですが、 Windows Update をあらかた実行した後で改めて再生してみるとまた以前と同様に異常終了してしまう問題が起きました。 Windows Update のログを見ると、 中には WMP (Windows Media Player) の DRM に関連したセキュリティアップデートがありました。 どうやら、これによって 「再生はできるがセキュリティに問題のある状態」 が 「セキュリティに問題は無いが再生すると異常終了する状態」 に変わってしまったように思えました。 そこで、WMP 関連の Windows Update をすべてアンインストールした後で WMP 9 (Windows 2000 用では最新) を再インストールしたところ、困ったことに症状が治りませんでした。 調べてみると、system32 フォルダ内にある WMP 関連の DLL が新しいままでした。 恐らくアンインストールしても共有 DLL は削除されず、 かつ古いファイルにロールバックもされないようです。 そこで、荒っぽい方法ですが system32 内にある次のファイルを手動で削除してから WMP 9 を再インストールしてみたところ、 無事（？）に古いファイルに置き換わり、 DRM 付きのファイルを再生できるようになりました。
ここに挙げたファイルには置き換える必要の無いものも含まれているとは思いますが、 細かい検証はしていません。
これでまた少し DRM が嫌いになりました（苦笑）。
新年明けましておめでとうございます。 ということで、また唐突に 2007 年に購入した CD を列挙してみます。 お気に入り度は 5 段階評価で 5 が最高に気に入った、です。
言うこと無し。すばらしい世界です。
これもまた言うこと無し。すばらしすぎる世界です。
残念ながら、あまり肌に合いませんでした。
狂っています。 Vicious Delicious の「ずっと絶頂」な感覚は本当にすごい。 音一つ一つの作り込み、パターンの贅沢さ、 何をとっても常軌を逸していると思います。
Becoming Insane と Change The Formality も大好きです。
このアルバムは元々 iTunes Music Store で購入していて 電子データでは持っていました。 しかしどうにも電子データだけだと無くなりそうで怖い。 コンピュータの電子データは不滅と考える人がまれにいるようですが、 実際には人的要因によって簡単に失われるものです。 そんなことで If I Ever Feel Better が聴けなくなるのは嬉しくないと思い、 またこの曲への敬意も込めて CD を購入。 このアルバムを私に教えてくれた友人の山道氏に、改めて感謝。
HMV 新宿店の店内放送で流れていたのを聴いて、 店員をつかまえて「今流してるアルバムください」と言って購入しました。 面倒くさい客です（苦笑）。
「モダン・ロックとエモの融合」、というコンセプトで結成されたそうですが、 メタルのにおいとプログレ的な音楽のための技巧も感じられる気がします。 もっとも、一番強い印象はエモだと思います。 店頭で惹かれたのは彼らのエモっぽさでしたしね。 Starlight Drive の 2 分 58 秒時点でのスネア三連打が一等級に好きです。 マニアックな部分ですが（苦笑）。 Girl Next Door も好きです。
以上、合計 10 枚でした。 正直に言うと、こんなに少ないとはショックです。 曲を作る時間や環境が悪かったこともあって曲を作るために刺激を得ようと考える機会も少なかったのだと解釈しています。
まあ、何はともあれ今年もよろしくお願いします。
「Unicode の点字パターン領域」
のページにて、
一覧表の行と列が反転しているという致命的な間違いを中川様よりご指摘いただきました。
ありがとうございます。
なお、同氏は
Unicode の点字領域にグリフを定義したフォントを同氏のウェブサイトにて制作、公開されています。
私が調べた限り Unicode の点字領域にグリフを持つ無料のフォントは非常に少なく
（例えば
Komikaze
など）、
さらに再配布などに関する使用条件が明示されているという点でも同氏のフォントは極めて貴重な物だと思います。
フリーフォントは使用条件が曖昧なものが多いですから。
ご興味のある方はチェックしてみてください。
中川氏のサイトへ
先日の一言を記事にしました。 「C# のポインタアクセス速度の検証」 という記事です。 まあ暇な人が暇つぶしに読むには良いかもしれません。
久方ぶりの更新です。 といっても気まぐれな一言を書き連ねるだけですが。
本日の遊び記録。 C# には unsafe ブロックではポインタが利用可能です。 配列のデータを先頭から順に参照していく場合には、 ポインタによるイテレーションがインデックスアクセスよりも高速と私は信じていたので、 「C# で」どのような結果になるのかベンチマークしてみることにしました。
今回の比較対象には、 インデクサ（大カッコと添字でのアクセス）でのアクセス、 恐らく .NET が内部で実装している専用列挙子によるアクセス、 ポインタを使ってのアクセスの 3 つを選びました。 計測には次のようなメソッドを用意し、これに長さが 50 万の byte 配列を与えて 100 回実行した結果を平均してみました（毎回同じ配列を渡している）。
static unsafe void Test( byte[] ary )
{
byte num;
// index access
Console.Write( Stopwatch.GetTimestamp()+"," );
for( int i=0; i<ary.Length; i++ )
{
num = ary[i];
}
Console.Write( Stopwatch.GetTimestamp()+"," );
// foreach
Console.Write( Stopwatch.GetTimestamp()+"," );
foreach( byte n in ary )
{
num = n;
}
Console.Write( Stopwatch.GetTimestamp()+"," );
// pointer iteration
fixed( byte* p = ary )
{
byte* q = p;
Console.Write( Stopwatch.GetTimestamp()+"," );
for( int i=0; i<ary.Length; i++ )
{
num = *q++;
}
Console.Write( Stopwatch.GetTimestamp()+"," );
}
Console.WriteLine();
}
私のノート PC (Pentium M 1.8GB, Memory 1GB)での実行結果は次のようになりました。 なおコンパイル時に最適化を有効にしています。
この結果から、どうやらポインタアクセスだけが他より遅いということが分かりました。 ・・・予想と違いました（汗）。 ちなみにコンパイル時に最適化を無効にした場合も同じ傾向が出ました。 続いて、これの int 型バージョンを作って実行してみたところ、次のような結果になりました。
こちらも同じように、ポインタアクセスは他の方法よりも遅い結果になりました。 とりあえず言えることは、明らかにポインタを使うメリットがある場合を除き、 下手にポインタを使うと逆にパフォーマンスを低下させることが十分ありうるようです。 うーん、少し意外な結果でした。
先日に引き続き、今度は音ファイル用アイコン集を更新してみました。 48x48 のサイズを追加し、さらに 256x256 のサイズ（Vista用）も追加しました。 興味のある方は アイコンのページ からどうぞ。
動画用アイコン集を更新してみました。 48x48 のサイズを追加したり、FLV 形式のものを追加したりしました。 興味のある方は アイコンのページ からどうぞ。
「アカデミック価格で買えるうちに」と考えて、 Adobe Photoshop CS3 と Microsoft Office 2007 Professional を買ってしまいました。 合わせて七万円後半。 ソフトにこれだけの金額をかけたのは生まれて初めてです・・・（苦笑）。 今月は論文書きで猛烈に忙しいので、 来月にでも Photoshop 購入記念で自作アイコンを一新しようかなと思ってみたり、みなかったり。
10/13追記。記事 「Windows 用ホットキー」 を２年ぶりに更新。
Java と C# の比較などを行っていました。 Java の仕様でトップクラスに嫌いな（笑） Checked Exception について調べていると、 Checked Exception 不要論が多く見つかります。 そんな中、Checked Exception と直接は関係が無い 「例外仕様をメソッド定義に書く」 Java の仕様に関して、面白い情報が見つかりました。 次の URL です。
C# and exception specifications
これはC# の言語設計者の一人が書いたもので、 例外仕様をメソッド定義に書く事を強制して実験した結果 （当然 Checked Exception も併用？）、 小さいプロジェクトでは生産性が向上したが、 大きなプロジェクトでは変わらないか逆に落ちたと書いています。 この記事にはメソッドが投げる例外はドキュメント目的と考える事もでき、 その場合はコードとして記述する（シグネチャに含める）よりもドキュメンテーション コメントに記述する方が良いとしています。 そして、C# は例外仕様をメソッド定義に書かなくなったようです。 あんまり読み込んでいないので多少間違っているかもしれませんが、 面白いなと思ったので走り書き。
追記です。 いつの間にか当サイト一番の人気記事となった 「知られざるバッチファイル」 を更新しました。 今回は変数の扱いについて加筆しましたが、 まだまだ書き残しが残っていますね・・・。
気まぐれに、当サイトのスタイル outliner 用のアウトライン抽出ロジックを改良してみました。 改良内容は、アンカーが設定された見出しのみアウトライン表示部にリンクを張り、 クリックするとその見出しの位置にスクロールする、というものです。 いや、単なるページ内リンクですけれども。
第六世代 iPod、つまり iPod Classic を買いました。 80GB のモデルですが、私にとって十分すぎる容量です。 iTunes のウリの一つに Cover Flow （アルバムのジャケット写真をずらりと並べてレコード屋でレコードを探す感覚でアルバムを選択できるインタフェース） がありますが、これが iPod 上で使えるようになっています。 しかし私は今まであまりアルバムアートを収集していなかったのでその恩恵が少ない。 これからは少しアルバムアートを集めてみる事にします。
iPod Classic で一つ困ったのは、愛用していた Winamp プラグイン ml_ipod でデータを管理できない事です。 iPod Classic は今までの iPod とデータベースの形式が変わったようで、 現状では ml_ipod で曲を転送すると iPod のデータベースが壊れてしまいます。 ml_ipod 側でも対応を急いでいるようなので、 しばらくは様子見です。
アルバムアートに関連しているのですが、 Winamp 5.5 のベータ版を使ってみました。 メディアライブラリの改善がめざましいですね。 アルバムアートを一覧表示するだけでなく取得する事もできるようになっています。 Winamp 5.5 がリリースされて、 ml_ipod が iPod Classic と Winamp 5.5 に対応すれば Winamp + ml_ipod なユーザが一番悔しい思いをしていたアルバムアートへの対応が実現します。 そのときが待ち遠しいです（笑）。
話は変わり、19日から21日の間、日本バーチャルリアリティ学会に行ってきました。 学会の会場は九州大学だったのですが、 しかし気温が三十度後半と暑い。 さらにフル装備のスーツ姿だったので食欲が失せるほどに暑すぎる。 今回は技術展示＋口頭発表で行ってきました。 内容は、私の研究室の先生が長年研究している最新型 触覚ディスプレイの ユーザビリティ問題解決と低価格化への布石、といったところです。 触覚ディスプレイと一口に言っても色々ありますが、 このディスプレイは重度視覚障害者に言語に変換できないような空間的な情報を提示するものです。 言語に変換できる内容は音声や点字に変換すれば良いので、 変換できないような情報を動的にディスプレイする機器、という位置づけです。 バーチャルリアリティ学会という名前からは福祉系の研究は遠い気がするのですが、 実際にはなかなかの数の研究がこの学会で発表されます。 人間の認知機構を「だます」事で現実でない現象を現実として認知させる事がバーチャルリアリティの基本的な考えだと思いますが、 ある感覚を失っている人に対して「別の感覚をだます」事であたかも失われている感覚を通して得るのと同じ体験を与える事ができる、 といった感じに応用すれば福祉に応用できる技術だったりするのですね。 発表を聞いた後で見に来てくださった方々も多く、 色々なフィードバックが得られて参加した甲斐のある学会となりました。
C# プログラムで例外が最後までキャッチされなかった時に表示されるダイアログを変える方法を調べました。 「C# の未対処例外ダイアログを変更する」です。 意外に簡単でビックリです。 さすがは .NET Framework、ですね。
テキストエディタ部品を選定していました。 メモ書きを気まぐれに一言書いていたところ、 長くなりすぎたので独立した記事にしました。 追加した記事は 「C# から使えるテキストエディタ部品」 です。 C# でテキストエディタを作りたい人には参考になるかも・・・いや、ならないでしょう（苦笑）。
Winamp のプラグイン ml_ipod を使って WAV 形式の音楽ファイルを iPod に転送する方法の備忘録（Winamp 5.35 / ml_ipod 3.0）。 まず Winamp.ini の ml_ipod セクションに次の一行を加える。
transcodeWavFiles=0
続いて Winamp の設定ダイアログを出して iPod Support の Transfers のページを表示。 ここの Upload タブで "Transcode incompatible files" にチェックを入れる。 以上を設定すると、 「WAV 形式でも iPod へ転送するが Transcoding は実際には行わない」 ようになる。 結果として WAV をそのまま転送可能となります。 なお曲名などはタグとしてファイルには書き込めないので Winamp の Media Library のデータベース上で設定します。
なんで WAV 形式でわざわざ、と思うかもしれません。 iPod に同じ曲を MP3 と Apple Lossless の両方の形式で転送して聴き比べたところ、 どうした事か MP3 の方が解像度が低いと感じたのです。 自宅で Winamp + ASIO プラグインで MP3 ファイルと WAV ファイルを聴き比べても違いがほとんど分からないのに、 iPod では違うと感じる。 という事は iPod の MP3 デコーダの音質が悪いという事なのかと心配になってしまい、 今度は WAV で転送して聴き比べてみようかなと思ったわけです。 まあ気分的な問題が大きいので、しばらく WAV で転送して遊んでみようかなと思います。
その後の追記。 以上の方法では WAV が Transcode されていました。 WAV そのまま転送できていません。 とりあえず今日は面倒くさいので iTunes で転送しておきます。
通学の行き帰りで書いていた記事 「Win64 開発」 が完成しました。 気が付くと日記ログを除外した HTML ファイルの中でサイズが一番大きい。 無駄に長くなっているわけではなく、 章立てをしっかりやった結果として長くなったので、 むしろ読みやすくなっているハズだと願います。
最近注意しているは文書の価値を高める事です。 文書の内容を正確にするなどは当然の話ですが、 文書がいつ書かれたものなのか、 いつ修正されたものなのかという時間的情報や、 関連キーワードといったメタ情報についても書くようにしました。 この他にも引用元の情報提示など色々と書くべき事を考えていると、 最終的に文書の形式が「論文」の形式になる事に気がつきました。 やはり、先人は偉大だなぁと思いました。
就職活動終了しました。 これで時間が増えると思いきや、逆に忙しい今日この頃です。
イヤフォン SHURE SE210 を買いました。 総評して、すばらしいです。 前の E3c よりも良いと思います。 今度は壊れないように、もっと大事に使おう（苦笑）。
最近買ったCDから2枚を取り出してプチレビュー。
サイケデリックトランスに分類される彼らですが、 もう完全にトランスを逸脱していると私は思います。 私とトランスという音楽は相性が悪く、 あまり良いと思う曲に出会えていなかったのですが、 この毒キノコだけは別格級で残りました。 特にこのアルバムはトランスから相当遠い位置にいる気がします。
Becoming Insane で「やられた」と思いました。 こんなにかっこいいメタルは聞いた事が無い。 そして Vicious Delicious がすごい。 ずっと絶頂のままで降ろしてもらえないような気分。 狂います。
ちまたでの評判は「weg らしくない」との事で賛否両論のようですが、 私は好きです。
こういう作品は曲単位で聴かないので曲ごとに感想は書きにくいのですが、 全体として良い作品だと思います。 いつも通り何が良いのかは言葉で表せませんが、 私は本能的にこの音を好みました。
ようやく就職活動が一段落付きました。 採用結果が返ってきたら一段落付いていなかった、 なんて事が無いよう願ってはいますが（苦笑）。
重度視覚障害者向けプログラミング環境 AiB Tools を更新しました。 今回の更新はスクリーンリーダー 95Reader でも読み上げできるようにするのが主な内容でしたが、 そのために何を行ったかと言うと、 .NET の GUI の中に Win32API を直接叩いてウィンドウを作成するという荒技です。
ウィンドウを生成する事自体は簡単です。 user32.dll の CreateWindowEx 関数を P/Invoke すれば良いだけですから。 難しいのは、.NETウィンドウ中に作った非.NETウィンドウの挙動がまったく変わってしまう問題を解決する事でした。 ウィンドウプロシージャを書き換えてメッセージをログ書き出しするなどして色々とハックしたところ、 どうやら .NET Framework はフォーカスを独自に管理しているらしく、 おかしな挙動はすべてそれが原因で起こっていると分かりました。 となれば .NET GUI 環境下ではその独自管理の流儀に従う必要があるわけで・・・ と書いているとキリがないので詳細は割愛しますが、 かなりの時間をかけた結果 .NET Framework を騙す事に成功し、 この問題を解決できました。 プログラミングの世界には魔法など無い、というのは私の信条ですが、 ソースも無く改変も不可能な .NET Framework を外側から騙すというのは私的に少し「魔法ちっく」な仕事です。 ですから少しだけ、「まあよくやった」と自分を褒めたい気分です。 疲れたし（苦笑）。
Technology & Persons with Disabilities Conference (CSUN 2007) より帰ってきました。 そして GTA: San Andreas で見た風景をいくつも見てきました（苦笑）。 それはさておき、CSUN レポートを時間を見ては書いていきたいと思っています。
本日、 知られざるバッチファイル の記事を更新しました。 プログラムの終了コードを判定する方法などが追加されています。
という事で明日から米国に一週間ほど行ってきます。 Technology & Persons with Disabilities Conference (CSUN 2007) という催し物に参加して色々と勉強してきます。 まあカリフォルニアでの催し物なので気楽に。 ゲーム GTA: San Andreas 中の都市 Los Santos がどれくらい Los Angeles に近いのか体感するのが密かな楽しみ（苦笑）。
気まぐれにドメインを取得しました。 sgry.jp というドメインです。 あっけないくらい簡単に取得できてしまってビックリでした。 何はともあれ、碧落には http://sgry.jp でアクセスできるようになりました。 ちなみに以前の URL でアクセスできなくなる、 というわけではありません。 しかし新しい URL は短くて良いなあ・・・自己満足度は高いです（笑）。
なんとなく「はじめに」のページを更新。 また各スタイルシートを再構築しました。
年明け早々わざわざ海外からロボットがやってきて掲示板に落書きをしていくようで、 当サイトの掲示板が落書き帳になってしまいました。 そこで、対応している暇がないので掲示板そのものを削除しました。 今までに書き込んで頂いた方々には申し訳がありません。 まあ、廃墟状態だったので誰も惜しまないと思ってはいますが・・・（苦笑）。
C/C++ のソースコードを解析して関数やクラス、 メソッド等のアウトラインを抽出するパーサを作り、 卒研で開発したシステム AiB Tools に組み込みました。 公開後初のアップデートです。
AiB Tools の AiB Edit は Ruby の「アウトライン」を抽出する機能があります。 要するにクラスやメソッドの構造をツリー表示する機能です。 しかし Ruby という言語は非常に動的な言語でして、 かなり静的な C++ からプログラミングを始めた私からすると別世界というレベルで動的です。 動的である事は Ruby の言語としての特質ですしそれはそれで魅力的なのですが、 既存のオブジェクトに固有の属性やメソッドを追加する 「特異メソッド」や「特異クラス」をどのようにアウトライン表示すべきかで困りました。 追加されたメソッド等は静的に宣言されたどのクラスにも属さないのですから。
特異クラスという概念をちょっとだけ例で説明してみます。
# Rubyist を定義 class Rubyist def writeRuby print 'print "Hello, Ruby!\\n"' "\n" end end # Rubyist の兄弟を連れてくる taro = Rubyist.new jiro = Rubyist.new # Rubyist の兄弟に Ruby のコードを書かせる taro.writeRuby jiro.writeRuby # 兄に Python を覚えさせる class << taro def writePython print 'print "Hello, Python!"' "\n" end end # Python のコードを兄弟に書かせる taro.writePython jiro.writePython
実行すると、次のような結果になります。
print "Hello, Ruby!\n" print "Hello, Ruby!\n" print "Hello, Python!" test.rb:25: undefined method `writePython' for #<Rubyist:0x296e39c> (NoMethodError)
class << taro として追加したメソッド writePython は taro に固有であり、 Rubyist クラスに属さないので jiro.writePython を実行すると 「そんなメソッド無いよ」 と怒られてしまうわけです。 このように、特異クラスを使って追加されたメソッドを Rubyist クラスの下に表示するわけにはいきません。 結局どうしたかというと、 "<< taro" というクラスが定義されたという事にしてそのクラスの配下に追加する事にしました。 この表示形式（モデル）は、友人に借りて少し読んだ書籍 「プログラミング Ruby - 達人プログラマーガイド」 に書いてあった（と思う）Ruby 内部における特異クラスの実装モデルに近いと思います。 ということで一人納得しつつ今年最後の綴り書きを終わります。 それでは良いお年を。
一つ新しいログ | 一つ古いログ