[ruby-dev:11484] Re: class Character (was: Ruby I18N)

In article <[e-mail]>,
  [e-mail] (Yukihiro Matsumoto) writes:

>   (c) 効率の良い方法があるかも or 効率悪くても関係ないかも
> 
>       Flyweight patternのような方法を使えば、効率はもうちょっ
>       とマシになるかも。あるいは文字そのものを扱う機会は実は
>       あんまり多くなくて効率が全体を左右することは無いかもし
>       れないとも考えています。

ひとつ思いついた効率化は、ひとつの文字列中の文字では文字クラスは一定な
ので、method dispatch を真面目にやらなくてもすむ場合もあるかも知れませ
んね。C から一つの文字列中の文字に関して連続して呼び出す場合の話ですが。

あと文字オブジェクトの allocation を避けるなら、かなりどころではなく乱
暴ですが、self にコードポイントの Fixnum を bind したうえで、文字クラ
スの method を呼び出してもいいかもしれないですね。(無理かも)

あと、互換性と効率の両面から、String::Byte::Character を Fixnum の
別名にするのはどうだろうか、と思っています。

>   なにが文字かという合意がとれそうにない
> 
> かつ
> 
>   まつもと(or Ruby)が「これが文字だ」と提供できる見識がない
> 
> ということに還元されます。要するに「ある局面(アプリケーショ
> ン)に嬉しい文字クラス」は定義できても、「どこでも嬉しい文字
> クラス」は定義できないだろうという悲観的な予想です。高橋さん
> が述べておられる、Code Unitを文字とするか、合成されたものを
> 文字とするか、ということひとつとっても、私には適切な判断がで
> きそうにありません。

これにはなんらかの割り切りが必要です。

優柔不断すぎるのは早すぎる決断と同程度にひどい目に合うことが多いので、
遅すぎない時期にそれなりな実装をしたほうがましです。

> これが「どこでも嬉しい文字列クラス」としてのStringを提供して
> いることとの大きな違いです。
> 
> よって、今の私の気持ちとしてはRuby標準の文字クラスは提供せず、
> 個々の人が自分なりの定義で導入するのに任せようかなあと考えて
> います。

たとえば、合成されたものを文字とするような文字クラスを導入可能にするん
でしょうか? それはとてもとても素晴らしいですね。

これは、端的にいえば「どこまで覚悟してるんだろう?」という疑問です。文
字列に関する仮定を「どこまで」捨てるつもりでしょうか、といってもかまい
ません。また、見識のなさを露呈/強制するような実装になるのではないかと
いうおそれ、ともいえます。

もちろん、見識抜きで定義する、そしてどんな見識も導入可能にする方法はた
しかに存在します。

Unix なファイル/標準出力に出す必要があればバイト列への変換インターフェー
スを定義し、正規表現との照合をするならアルファベット Σ の定義を与えた
上で Σ の並びへの変換インターフェースを定義し、...

といった具合に、外的要因から必然的に決まるインターフェースをひとつひと
つ定義していくという方法です。たぶん文字クラスを使わないでインターフェー
スを定義していくことも可能でしょう。Mix-in でそういうインターフェース
の実装を混ぜていくことによって自由に文字列クラスを作っていける、という
のも Ruby らしくていいかもしれません。

これはこれでとても挑戦しがいのあるテーマではありますが、見識抜きで定義
するという見識と覚悟が必要です。ついでにいえば、すでに String にいろい
ろなインターフェースが存在し、それと互換性があるように定義するのはかな
り厄介かもしれません。

もし、本当にこの方向性で進めるというのなら、それはとてもとても素晴らし
いのですが、中途半端にやるのなら誰にとっても嬉しくないものになるでしょ
う。文字のことなんか気にしたくない人にとっては異なる文字列から出てきた
異なる意味の番号に困惑し、文字をいじくりたい人にとっては制限が多すぎて
全然嬉しくない、と。

で、どこまで覚悟してます?
-- 
[田中 哲][たなか あきら][Tanaka Akira]
「くっだらないコト聞いちゃったねー$(C⊇ ごっめーん$(C⊇」
  (魔法使い養成専門 マジックスター学院 2, 南澤ミヅキ)