ruby-dev

[ruby-dev:11428] からの続きですが、threadは切りました。

At Wed, 8 Nov 2000 14:26:14 +0900,
matz@zetabits.com (Yukihiro Matsumoto) wrote:

> 「文字オブジェクトの必要性」を感じさせてくれる説得メールを待っ
> てます。;-)

って事で、Characterクラスを導入した方が嬉しい理由を上げてみます。

# class Character -> 文字クラス
# class Stringとそれ以下すべてのクラス -> 文字列クラス
# class Stringを表わすときは class Stringと書く
# 個々のコード毎に文字列クラスの下位クラスを作る事を前提としています

user side
=========

文字列クラスの method `[]'が文字クラスの instanceを返す事により、文字と
いう文字列よりも粒度の細いオブジェクトを自然に扱う事が可能


implementer side
================

文字を抽象化する事により将来内部実装に変更が必要になったときにも user
sideへの影響を小さくする事が可能


互換性問題
==========

文字列クラスを「文字クラスを要素として持つ Arrayクラス」として実装せず、
現在の文字列クラスと文字クラスを独立させて実装することにより文字列クラス
の method `[]'や `[]='など将来文字クラスを返す事を期待される method以外
の互換性は確保できるのではないだろうか？

さらに文字クラスで Character#to_iの様に従来の String#[]が返す Fixnumを取
りだす事を可能にする事により互換性を極力保持する様にする。

速度的問題
==========

まず「おおむね一つの文字コード系で閉じているのが普通」であり、「ほとんど
の場合文字列クラスだけで事足りる」を前提とした場合、文字クラスの実装はあ
る程度遅くても良いのではないでしょうか？

String#[]=などは現在の実装と比べてコストの高い methodとなるが、上記の仮
定が真であれば文字列クラスの method `[]='の実装は self.ces == arg.cesの
比較分だけしかコストが増えないので問題は無いのではないか？

method []=の中で、argumentとして渡された文字クラスの instanceは selfが保
持可能なコードに「自動的」に変換されるか、または Exceptionを投げる事にな
ると思う。

(この自動変換にまつもとさんは抵抗があると書かれていますが、もし良ければ
理由を教えてください)

String#[]=の場合はコードを持たないただの byte列なので渡された文字クラス
の instanceが持つ byteを指定された場所にただ代入する。今と変らない。文字
列としての一貫性をただの byte列である Stringクラスの instanceに求めては
いけない。

まとめ
======

現在の文字列クラスに影響を与えず、さらに粒度の細かな文字クラスを導入する
事も可能なはずである。独立した実装の二つのクラスが「シームレスに統合可能
なら」ば、kitchen sinkを目指す Rubyとしては取り入れるべきではないだろう
か？

ps. いくつか IRCの会話から引用させてもらいました(__) > 某氏。
--
         yashi

Thread

Prev Next

In This Thread

Prev Next