[ruby-dev:4830] Re: to_i,to_s の素朴な疑問

まつもと ゆきひろです

In message "[ruby-dev:4829] Re: to_i,to_s の素朴な疑問"
    on 99/02/08, HQss_YasuiS/[e-mail] <HQss_YasuiS/[e-mail]> writes:

|でも、数学的な雰囲気を持たせることをキープするなら、 + メソッドは
|Numeric だけに限定すべきですよね。

その通りです．その辺が妥協の産物なんですね．

|>えーと，「右辺(または引数)の型が数値であっても文字列であって
|>も構わない」というのは「構わない」と思う時点で「型の認識を阻
|>害する」と思うのですが，私の考えは違ってます？
|
|ここで言う「型が何であっても構わない」とは、合理性を伴った「構わない」
|という意味で、当然、そのクラスに相応しい、かつ、必要なメッセージでな
|ければならないことは言うまでもありません。

では，今回の Numeric+String=Numeric は合理性があるんですか？

いや，ある局面で手間が減るのは肯定しますが，合理性ってのはもっ
と強い言葉ですよね．しかも，現状の仕様を変更しようと言うので
すから，変更を望む人に合理性を示すことを求めるのは合理的です
よね． ;-)

|それと、はっきりと区別しておかなければならないのは、引数の多態？（こんな
|言葉があるかどうかは別にして）は、rubyインタープリタの仕様と言うより
|クラス設計論の問題ではないですか。さらに、まつもとさんは認めるか否かに
|係わらず、既に添付ライブラリやユーザが自由に作成するクラスにおいて、
|バンバン作られているじゃないですか。

さすがにRubyで書かれているプログラムの善し悪しにまでは責任は
持てません．また言語がそのような枷を与えるべきではないと考え
ます．Pascalじゃないんだし．しかし，Rubyが標準的に備えるクラ
スについては私に責任があることは確かです．

|本来なら標準クラスは、インタープリタと１枚岩にするのではなく、添付ライブ
|ラリのように切り離してruby語で作成し、一般のrubyユーザにも開放して欲しい
|と思っています（これは単なる意見です。聞き流してください）。

この場合，標準クラス(たとえばString)をどうやって定義するんで
しょうね．なお，標準クラスのメソッドをRubyレベルで再定義する
ことは可能です．

|>えーと，私の考えでは，すくなくともRubyにおいては仕様というの
|>は「仕様だから仕様である」のではなく，「気持ち良い，あるいは
|>間違いが発生しにくいので仕様としよう」であるべきだと考えてい
|
|なるほど。よくわかります。でも今回のケースは該当しませんよね。

え？ 該当しないんですか？

|わかりました。現時点で私が考える案は次の通りです。
|# でも、１は多分無理かなあ
|
|１．ストリームからデータを読むとき少なくとも、String、Numeric
|　　が区別できること（これができれば２は不要です）。
|
|２．１が駄目な場合、Numericの+メソッド引数に、Stringも認める。

うーん，UNIXのバイトストリームからNumericを直接取り出すのは
意味があるようなないような．バイトストリームには構造って情報
がないんですから，推測することになるんですが，コンピュータに
よる推測はいつも正しいとは限りませんからねえ．

String#scanf(pat) のようなものは可能ではないかと思いますが．

|ファイルストリームからのデータリードは、Stringとしてしか受け付けられないので、
|本当は数値なのに、NumericでなくStrirngで読み込まれます。そのデータを数値として
|引数に与えようとした場合、その時点で、to_iを使ってNumericに変換しなければなり
|ませんよね。これが不自然であり非合理的じゃないか、と言っているのです。面倒なのは
|これを回避しようとすると、サブクラスを定義しその都度requireしなれればならない
|ことです。こちらの方が不自然です。

ちょっと待ってください．ファイルストリームの内容はフラットな
バイト列(文字列と言っても構いませんが)であるというのはRubyが
依存しているUNIX文化の一部です．ですから，ストリームから読み
込んできたデータはどうやっても文字列で「本当は数値」なデータっ
てのは存在しないでしょう．数値風のフォーマットを持っているし，
数値として処理したいデータはいっぱいあるでしょうけど．その意
味(どの文字列が数値を意味するか)は人間が与えてやる必要がある
と私は思います．

もちろんファイルに直接データを読み書きできる文化が存在するこ
とを認知はしてますが，現状と違う文化の「自然」をいきなり持っ
てこられても当惑します．バイトストリームから意味を取り出すた
めにはユーザが構造の情報を与えてやる必要があると思うのですが，
それが「変換」という処理なのだと思います．

それでも，オブジェクトを直接読み書きしたいのならmarshalを使
うとかunpackを使うとかいろいろ方法はあると思います．要は構造
を明示してねってこと．

|>すが，今回に関してはメリット・デメリットをちゃんと評価すると
|>トータルでマイナスが多そうだというのが今の私の結論です．
|
|全く理解できませんね！

はあ，そうですか．理解して頂く必要があるわけではないんですが，
あまり議論を進めるのに役立つ言明ではないと思いますね．

まあ，Numeric+String=Numericのメリット，デメリットをまとめて
おきましょう．

  * メリット

    ストリームから読み出した数値(風のフォーマットを持つ文字
    列)をわざわざ数値に変換しなくても計算できる(引数または右
    辺に登場すれば)．

  * デメリット

    数値風のフォーマットを持つ文字列は数値ではないので，左辺
    あるいはレシーバに登場したときにはやはり文字列として動作
    してしまう

    各演算に文字列に対する数値風のフォーマットのチェックが入
    るため実行効率が悪くなる(可能性がある)

    どのメソッドが数値風の文字列を数値として扱い，どのメソッ
    ドがいつも文字列として扱うかを覚えている必要がある(いや，
    ぜーんぶ変更してしまえば，覚えてなくても良いですが，今度
    はやりすぎになりそう)

    Rubyインタプリタおよび標準ライブラリについてかなり大規模
    な変更を行う必要がありそう

    この仕様によりユーザが数値と文字の相互変換は全部自動で行
    われると期待してしまう(Awkみたいに．実際にはtypelessの言
    語であるAwkのようにはいきません)

    この仕様によりそれぞれまったく異なる型のオブジェクトであ
    るはずの数値と文字の認識が曖昧になる．あるいはAwkにおけ
    る var+0, val+"" のような妙なイディオムが登場する

    この仕様によりエラーの発見が遅れる可能性がある

といった感じでしょうか．デメリットのうしろ3つは似たようなも
のですからひとつに縮退しても構いませんケド．

一方，ユーザがなんらかのかたちで構造を指定する scanf/unpack
のようなタイプについては問題ないと思ってます．こちらについて
は実装する手間だけですね．

|安井＠日立造船  e-mail: [e-mail]
|# 「数値」を表す「文字列」を、「数値」として扱いたいと考えるのは自然だと思う。

型のある言語で変換を要求するのも自然だと思うんですが．

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