[#9052] bang method returns string always — WATANABE Hirofumi <eban@...>

わたなべです.

92 messages 2000/02/01
[#9054] Re: bang method returns string always — matz@... (Yukihiro Matsumoto) 2000/02/01

まつもと ゆきひろです

[#9060] Re: bang method returns string always — WATANABE Hirofumi <eban@...> 2000/02/02

わたなべです.

[#9062] Re: bang method returns string always — matz@... (Yukihiro Matsumoto) 2000/02/02

まつもと ゆきひろです

[#9070] Re: bang method returns string always — Wakou Aoyama <wakou@...> 2000/02/03

青山です。

[#9082] Re: bang method returns string always — "NAKAMURA, Hiroshi" <nakahiro@...> 2000/02/04

なひです.

[#9083] Re: bang method returns string always — matz@... (Yukihiro Matsumoto) 2000/02/04

まつもと ゆきひろです

[#9259] ruby object — Minero Aoki <aamine@...> 2000/02/20

あおきです。

[#9263] Re: ruby object — matz@... (Yukihiro Matsumoto) 2000/02/21

まつもと ゆきひろです

[#9264] Re: ruby object — Minero Aoki <aamine@...> 2000/02/21

あおきです。

[#9266] Re: ruby object — matz@... (Yukihiro Matsumoto) 2000/02/22

まつもと ゆきひろです

[#9084] Re: bang method returns string always — "NAKAMURA, Hiroshi" <nakahiro@...> 2000/02/04

なひです.

[#9096] Re: bang method returns string always — Kazunori NISHI <kazunori@...> 2000/02/04

西@九大です。

[#9100] Re: bang method returns string always — matz@... (Yukihiro Matsumoto) 2000/02/04

まつもと ゆきひろです

[#9154] Re: bang method returns string always — Kazunori NISHI <kazunori@...> 2000/02/08

西@九大です。

[#9158] Re: bang method returns string always — matz@... (Yukihiro Matsumoto) 2000/02/08

まつもと ゆきひろです

[#9170] Re: bang method returns string always — Kazunori NISHI <kazunori@...> 2000/02/09

西@九大です。

[#9171] Re: bang method returns string always — matz@... (Yukihiro Matsumoto) 2000/02/09

まつもと ゆきひろです

[#9173] Re: bang method returns string always — Koji Arai <JCA02266@...> 2000/02/09

新井です。

[#9206] Re: bang method returns string always — nobu.nakada@... 2000/02/13

なかだです。

[#9207] Re: bang method returns string always — "Akinori -Aki- MUSHA" <knu@...> 2000/02/13

 knuです。

[#9208] Re: bang method returns string always — nobu.nakada@... 2000/02/13

なかだです。

[#9211] Re: bang method returns string always — matz@... (Yukihiro Matsumoto) 2000/02/13

まつもと ゆきひろです

[#9212] Re: bang method returns string always — "Akinori -Aki- MUSHA" <knu@...> 2000/02/13

 knuです。

[#9213] Re: bang method returns string always — Kazuhiro Yoshida <moriq.kazuhiro@...> 2000/02/14

もりきゅうです。ゴミまき。

[#9214] Re: bang method returns string always — gotoken@... (GOTO Kentaro) 2000/02/14

ごとけんです

[#9215] Re: bang method returns string always — WATANABE Hirofumi <Hirofumi.Watanabe@...> 2000/02/14

わたなべです.

[#9218] Re: bang method returns string always — Kazuhiro Yoshida <moriq.kazuhiro@...> 2000/02/15

もりきゅうです。

[#9219] Re: bang method returns string always — matz@... (Yukihiro Matsumoto) 2000/02/15

まつもと ゆきひろです

[#9220] Re: bang method returns string always — Kazuhiro Yoshida <moriq.kazuhiro@...> 2000/02/15

もりきゅうです。

[#9222] Re: bang method returns string always — Koji Arai <JCA02266@...> 2000/02/15

新井です。

[#9224] Re: bang method returns string always — matz@... (Yukihiro Matsumoto) 2000/02/15

まつもと ゆきひろです

[#9085] xmalloc() in Windows — "Shigeo Kobayashi" <shigeo@...>

小林です。

38 messages 2000/02/04

[#9134] Re: site_ruby — gotoken@... (GOTO Kentaro)

ごとけんです

24 messages 2000/02/07
[#9135] Re: site_ruby — WATANABE Hirofumi <Hirofumi.Watanabe@...> 2000/02/07

わたなべです.

[#9143] Re: site_ruby — nobu.nakada@... 2000/02/07

なかだです。

[#9161] Re: site_ruby — gotoken@... (GOTO Kentaro) 2000/02/08

In message "[ruby-dev:9143] Re: site_ruby"

[#9290] [fix] String#* with huge string — EGUCHI Osamu <eguchi@...>

えぐち@エスアンドイー です。

17 messages 2000/02/26
[#9293] Re: [fix] String#* with huge string — matz@... (Yukihiro Matsumoto) 2000/02/26

まつもと ゆきひろです

[#9294] Re: [fix] String#* with huge string — EGUCHI Osamu <eguchi@...> 2000/02/27

えぐち@エスアンドイー です。

[#9297] GC Problem ? — "Shigeo Kobayashi" <shigeo@...>

小林です。

23 messages 2000/02/27

[ruby-dev:9170] Re: bang method returns string always

From: Kazunori NISHI <kazunori@...>
Date: 2000-02-09 07:15:48 UTC
List: ruby-dev #9170
西@九大です。

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 )
------------------------------------------------------------------

In This Thread