From: matz@... (Yukihiro Matsumoto)
Date: 1999-02-09T16:24:51+09:00
Subject: [ruby-dev:4897] Re: to_i,to_s の素朴な疑問

まつもと ゆきひろです

In message "[ruby-dev:4895] Re: to_i,to_s の素朴な疑問"
    on 99/02/09, HQss_YasuiS/hq_ss@omssv.hq.hitachizosen.co.jp <HQss_YasuiS/hq_ss@omssv.hq.hitachizosen.co.jp> writes:

|>その通りです．その辺が妥協の産物なんですね．
|
|ふむふむ。それと、メッセージ評価に優先順位を与えていますね。
|つまり、実装がシンプルでなく複雑だと。

その通りです．既にお気付きかも知れませんが，Rubyが提供してい
るものは「一見シンプルで自然」なモデルというだけで，本当にシ
ンプルかどうかと言うと実は違います．特に

|特に、数学的演算オペレータについては、「気持ち良い」「誤解がない」
|が優先され、合理性やオブジェクト指向的な自然さは後回しにされてしま
|った感が拭えません。

オブジェクト指向的自然さと言うと

|1 + 2 * 3 => 7 #ruby風
|1 + 2 * 3 => 6 # Smalltalk風（これが不自然だと）

のようなののことですね．だとするとそうです．オブジェクト指向
的自然さよりも「普通の」プログラミング言語における自然さの方
を優先してます．「自然さ」というのは視点によって変わるし，時
として矛盾することもあるんですね．

|marshal や unpack は ruby の機能でした？ 

はい，組み込みの機能です．

|>  * デメリット
|>
|>    数値風のフォーマットを持つ文字列は数値ではないので，左辺
|>    あるいはレシーバに登場したときにはやはり文字列として動作
|>    してしまう
|
|うーん。これがデメリットかどうかは異論があります。
|文字列がレシーバのときは文字列として振る舞ってもらわないと逆に
|困るのでは。

ええ，対立する異論があるのは承知しています．つまり，ここで対
立がある以上すべての人を満足させることは不可能であることも意
味しています．とすると，私は私の喜ばせたい人を喜ばせることを
選択します．それはもしかすると安井さんではないかも．

|marshal はどうするのですか？

書き出しは

  file = open("path", "w")
  Marshal::dump(obj, file)

読み込みは

  file = open("path", "r")
  obj = Marshal::dump(file)

です．これでobjのコピーを取り出せます．これは構造情報と一緒
にファイルにオブジェクトを書き出しますので，問題なしですね．

|# self.rubyが段々とミックスかハイブリッドに見えてきた。

かならずしもsimple is bestというポリシーの言語ではないことは
確かです．
                                まつもと ゆきひろ /:|)