From: Kazunori NISHI <kazunori@...>
Date: 2000-02-09T16:15:48+09:00
Subject: [ruby-dev:9170] Re: bang method returns string always

西＠九大です。

From: matz@netlab.co.jp (Yukihiro Matsumoto)
> cascadingとchainingは違うもので、一般的には置換可能ではない
> ですよね。bang method ではたまたま一致しますが。今回 bang

はい、置換可能ではありません。

> method の挙動を変えたかったのは no nang method と統一したかっ
> たからで、そういう意味では bang method に対してしか有効でな
> い cascading はあまり魅力的ではないです。

なんとーっ！「bang method 内の統一」だけでなく、「no bang method との
規格統一(？)」という目的もあったのですか。後者が見えていませんでした。
すいません。(やはり途中から話に入るとダメですね)。てことは、例えば、

  array = string.gsub('xxx','yyy').downcase.split

とか書いている部分で、「string は変更後の値を保持させよう」と思い、

  array = string.gsub!('xxx','yyy').downcase!.split

とするも動かなくなってガックリ。精神衛生上、悪いよー！みたいな？確かに
それはあるかも。結局 '!'が複数の意味(機能)を持つ現状もよろしくないと。

> あまり cascading が欲しいと思った局面に陥ったことがないんで、
> 情熱を持てないんですが、

ここが結構ポイントで、今回の「gsub! の変更」は機能的に cascading を意
味して(＝欲して)いると見えるのです。で、cascading をやろうとして、それ
が欲しくないとは？？？な気分です。即ち、先程の例で言えば、最初から、

  array = string{gsub!('xxx','yyy'); downcase!; split}

みたいに cascading で書いておけば(表記法は例え)、というか、全て string 
に対するメッセージにしてしまえば、それぞれのメソッドが何を返そうが何の
問題もないのに、なぜ各メソッドが self を返すようにわざわざ変更してまで
chain で繋ぎたいのだろうか？と疑問を感じていたのでした。
＃自己破壊でないといけないので、この例では、多少無理がありますが

> せん(かえって残酷か)。yourselfについてはいまだ「それなに？」
> 状態なのでなんとも言えません。ていうか、それなに？ まじで。

「メッセージの receiver(の self)」です。単に

  class Object
    def yourself
      self
    end
  end

なだけです。上の例(良い例ではないですが)をひきずりますと、最後が split 
でなく、その string 自身を欲しい(代入したい)場合など、猛烈に便利です。

  string2 = string{gsub!('xxx','yyy'); downcase!; yourself}

このように、cascading との相性が良いので、(まつもとさんが)それと同様に 
yourself の必要性も感じてないだろうな、というのは予想してました。

ていうか、cascading messages をサポートしていない言語での yourself の
存在意義って何なんでしょうね。。。(話を逸らさねば)

> ほっとかれた方がいろいろ楽しめてよろしいんでは(相当残酷か)。

無反応が一番残酷ですよ。なんか、大勢の輪の中心で一人で黙々とスイカ割り
してる、みたいな。嘘でもいいので何か言ってよー！みたいな。でも、「右」
とか「もっと左」とか言うアドバイスは要りません。(いや、念のため)

>   * Rubyにおけるcascadingの意味とあり方
>   * それから求められる機能を実現する文法
>   * その文法の分かりやすさ
>   * Rubyの他の部分の文法との整合性
> 
> などではないでしょうか。

ふむふむ。ちょっと考えてみます。

> 嬉しくなさそう」、「instance_evalでいいじゃん」という印象が

cascading の採用は、機能的には無意味で、「同一オブジェクトに対して連続
してメッセージを投げる」事が簡潔に表現できる、という事がメリットになり
ます。ですから、instance_eval は長いのでその要件を満たしておらず、あく
まで文法的にサポートして欲しいと思っています。

話は逸れますが、そもそも、instance_eval という名前は好きではないです。
直観的には「自分のさらに instance に対して eval する」みたいで、最初、
全然意味がわかりませんでした。多分、instance_variables 等との整合性、
というか Ruby の世界観的には矛盾なくまとまっていると思いますが。

> 強すぎです。Smalltalkのようなコンパクトな文法であれば利用価
> 値が出てきそうですが、もう記号が残ってないぞ。

記号がないというのが、手も足も出ませんね。よくぞここまで矛盾なく使い切っ
たものです。というか、Smalltalk が「コンパクトな文法」であるというのは、
どういった観点からなのでしょうか？(他意はなく、純粋に質問です)

------------------------------------------------------------------
九州大学大学院システム情報科学研究科 情報工学専攻 博士後期課程三年
      西 和則   ( e-mail: kazunori@swlab.csce.kyushu-u.ac.jp )
------------------------------------------------------------------