2011/05/24

コードの所属

日常出会うプログラミングの問題の多くにおいては、 コードを書くこと自体は難しいことではなく、 むしろそれを後から参照できるように「適切な名前をつけて」「適切な置き場所を見つける」 ことの方がはるかに難しい。

クラスベース(メソッドがひとつのクラスに従属するタイプ) のOOPがこんだけ流行った理由のひとつは、この置き場所問題に 簡単なrule of thumbを与えたからかもしれない。そのコードが主として作用する 「もの」を見つけ、それをクラスにしてその名前空間に放り込んでしまえば良いのだ。 クラスをどう名づけるかという問題は依然として存在するものの (そしてJavaのクラス名一覧を眺めると名付け問題についてはうまく解決できていない であろうことが推し量られる)、一度クラスが決まれば場所が決まるという 安心感は大きい。

コードが2つの種類の「もの」の間に作用する場合とか、 コードが抽象的すぎて作用する「もの」を抽象的な性質でしか示せない場合とかは このrule of thumbがうまく使えない。クラスベースOOPで分類に困るケースって だいたいこんなところだと思う。

CLOSのマルチメソッドやHaskellの型クラスにはそういう困難は無いけれど、 場所問題の解決は示してくれないので、プログラマが自分で考えないとならない。 Haskellの事情はよく知らないけど、CLOSの人気が出ないのはそのへんにも 理由があるやもしれぬ。

★ ★ ★

何でこんなことを思ったかというと、長年頭の隅にひっかかってた 「場所問題」にひとつけりがついたのだ。

Unicodeのコードポイントとutf-8との変換を行うルーチンって、 これまで必要に応じて何回も書く機会があり、Gaucheに標準でつけときたいな と思ってたんだけど、どうも適切な置き場が見つけられなくて、 一から書いても10行くらいだから、結局毎回書いていた。 Gaucheの内部エンコーディングがutf-8でコンパイルされていれば コードポイントを文字にしてI/Oするだけで変換できるんだが、 「integerで表現されたコードポイントをutf-8のオクテット列に」とかその逆、 っていうのは内部エンコーディングに関係なく必要になるし、 関係なく書ける処理である。 内部エンコーディングに関わらないんで、文字や文字列の処理と 同じ場所に放り込むのは落ち着かない。入出力とも違う。 処理の作用する対象は整数だけど、数値モジュールでもない。

R6RSやR7RS draftのstring-downcaseやstring-titlecaseの 実装をしていて、これはUnicode Standard Annex #29の Unicode Text Segmentationをちゃんと実装しないと書けないという ことに気づいて、結局そのへんの処理がtext.unicodeというモジュールの 形を取ってきたところで、上の「コードポイントとutf-8との変換」も ここに属する処理であることに気づいた。 内部エンコーディングにかかわらず、Unicode Standardで決められてる 何かを扱うモジュール、というわけだ。

Tags: Programming, Gauche