From: matz@... (Yukihiro Matsumoto) Date: 1999-02-08T16:42:28+09:00 Subject: [ruby-dev:4830] Re: to_i,to_s の素朴な疑問 まつもと ゆきひろです In message "[ruby-dev:4829] Re: to_i,to_s の素朴な疑問" on 99/02/08, HQss_YasuiS/hq_ss@omssv.hq.hitachizosen.co.jp 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: yasuisu@omssv.hq.hitachizosen.co.jp |# 「数値」を表す「文字列」を、「数値」として扱いたいと考えるのは自然だと思う。 型のある言語で変換を要求するのも自然だと思うんですが． まつもと ゆきひろ /:|)