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

まつもと ゆきひろです

In message "[ruby-dev:11472] Re: class Character (was: Ruby I18N)"
    on 00/11/11, Yasushi Shoji <[e-mail]> writes:

|その後にまつもとさんがあげてる 3つの点を克服すれば Characterクラスは採用
|されるのかな…。最後の「効率…」は、文字操作を行う場合も文字列操作の並の
|速度が出ないと採用されないってことでしょうか？

3つの点ってのは[ruby-dev:11454]の

  (a) そんなには嬉しくないような
  (b) いったん作ると手に負えない程ヘビーになりそうな
  (c) 効率がめちゃめちゃ悪くなりそうな

のことだと思います。実はこれらは対等ではなくて、

  (a) 実はあれば嬉しいこともあるだろうとは思ってます。

      田中哲さんのメール[ruby-dev:11450]の内容に(フォローし
      きれてないところはあっても)反対しているわけではないの
      です。繰り返しになりますが、「この文字の空白か」とかを
      判定するメソッドを用意するなら文字オブジェクトが適切な
      場所だと思ってもいます。

  (b) こいつは最大の大問題

      ちょっと長くなりそうなので、後述。

  (c) 効率の良い方法があるかも or 効率悪くても関係ないかも

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

と思ってます。つまり、(a)や(c)はさほど問題でない可能性がある
のです。で、「最大の大問題」たる(b)というのは実は

  なにが文字かという合意がとれそうにない

かつ

  まつもと(or Ruby)が「これが文字だ」と提供できる見識がない

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

これが「どこでも嬉しい文字列クラス」としてのStringを提供して
いることとの大きな違いです。

よって、今の私の気持ちとしてはRuby標準の文字クラスは提供せず、
個々の人が自分なりの定義で導入するのに任せようかなあと考えて
います。

                                まつもと ゆきひろ /:|)