[#3747] constants (or class vriable?) — Wakou Aoyama <wakou@...>

青山です。

20 messages 1998/12/06
[#3751] Re: constants (or class vriable?) — Shin-ichro Hara <sinara@...> 1998/12/07

原です。

[#3763] Re: constants (or class vriable?) — Wakou Aoyama <wakou@...> 1998/12/07

青山です。

[#3764] Re: constants (or class vriable?) — matz@... (Yukihiro Matsumoto) 1998/12/08

まつもと ゆきひろです

[#3767] Re: constants (or class vriable?) — kjana@... (YANAGAWA Kazuhisa) 1998/12/08

In message <199812080034.JAA05946@picachu.netlab.co.jp>

[#3826] ruby 1.1d0 released — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

35 messages 1998/12/16

[#3873] (?: ) does not work? — shugo@... (MAEDA Shugo)

前田です。

15 messages 1998/12/19

[#3881] I want to catch all jump — shugo@... (Shugo Maeda)

前田です。

17 messages 1998/12/21
[#3895] Re: I want to catch all jump — matz@... (Yukihiro Matsumoto) 1998/12/22

まつもと ゆきひろです

[#3894] ruby 1.1d1 released — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

25 messages 1998/12/22

[#3899] interpreter reinitialization — shugo@... (Shugo Maeda)

前田です。

22 messages 1998/12/22
[#3923] Re: interpreter reinitialization — matz@... (Yukihiro Matsumoto) 1998/12/23

まつもと ゆきひろです

[#3926] Re: interpreter reinitialization — shugo@... (Shugo Maeda) 1998/12/23

前田です。

[#3931] Re: interpreter reinitialization — matz@... (Yukihiro Matsumoto) 1998/12/24

まつもと ゆきひろです

[#3956] Re: interpreter reinitialization — shugo@... (Shugo Maeda) 1998/12/24

前田です。

[#3960] Re: interpreter reinitialization — matz@... (Yukihiro Matsumoto) 1998/12/24

まつもと ゆきひろです

[#4002] config.guess — Koji Arai <JCA02266@...>

新井です。

24 messages 1998/12/26
[#4039] Re: config.guess — matz@... (Yukihiro Matsumoto) 1998/12/29

まつもと ゆきひろです

[#4045] Re: config.guess — Koji Arai <JCA02266@...> 1998/12/31

新井です。

[#4047] Re: config.guess — matz@... (Yukihiro Matsumoto) 1999/01/01

まつもと ゆきひろです

[#4048] Re: config.guess — Koji Arai <JCA02266@...> 1999/01/01

新井です。

[#4049] Re: config.guess — matz@... (Yukihiro Matsumoto) 1999/01/02

まつもと ゆきひろです

[#4050] Re: config.guess — Motoyuki Kasahara <m-kasahr@...> 1999/01/04

笠原です。

[#4030] module Precision — gotoken@... (GOTO Kentaro)

ごとけんです

78 messages 1998/12/28
[#4310] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/01/21

ごとけんです

[#4311] Re: module Precision — matz@... (Yukihiro Matsumoto) 1999/01/21

まつもと ゆきひろです

[#4312] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/01/21

ごとけんです

[#4317] Re: module Precision — keiju@... (石塚圭樹 ) 1999/01/21

けいじゅ@日本ラショナルソフトウェアです.

[#4364] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/01/25

ごとけんです

[#4478] Re: module Precision — matz@... (Yukihiro Matsumoto) 1999/01/28

まつもと ゆきひろです

[#4506] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/01/30

ごとけんです

[#4552] Re: module Precision — matz@... (Yukihiro Matsumoto) 1999/02/01

まつもと ゆきひろです

[#4557] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/02/01

ごとけんです

[#4632] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/02/03

ごとけんです

[#4647] Re: module Precision — keiju@... (石塚圭樹 ) 1999/02/03

けいじゅ@日本ラショナルソフトウェアです.

[#4648] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/02/03

ごとけんです

[#4633] Re: module Precision — matz@... (Yukihiro Matsumoto) 1999/02/03

まつもと ゆきひろです

[#4636] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/02/03

ごとけんです

[#4836] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/02/08

ごとけんです

[#4843] Re: module Precision — keiju@... (石塚圭樹 ) 1999/02/08

けいじゅ@日本ラショナルソフトウェアです.

[#4849] Re: module Precision — gotoken@... (GOTO Kentaro) 1999/02/08

ごとけんです

[#4924] Re: module Precision — keiju@... (石塚圭樹 ) 1999/02/09

けいじゅ@日本ラショナルソフトウェアです.

[#4976] a genericity — gotoken@... (GOTO Kentaro) 1999/02/10

ごとけんです

[#5008] Re: a genericity — keiju@... (石塚圭樹 ) 1999/02/11

けいじゅ@日本ラショナルソフトウェアです.

[#5018] Re: a genericity — gotoken@... (GOTO Kentaro) 1999/02/11

ごとけんです

[#5171] Re: a genericity — keiju@... (石塚圭樹 ) 1999/02/16

けいじゅ@日本ラショナルソフトウェアです.

[ruby-dev:3865] Re: List()

From: Shin-ichiro Hara <sinara@...>
Date: 1998-12-18 09:34:33 UTC
List: ruby-dev #3865
原です。

In message "[ruby-dev:3855] Re: List()"
    on 98/12/17, MAEDA Shugo <shugo@aianet.ne.jp> writes:

> 前田です。

> class StringScanner
>   include Enumerable
>   
>   def initialize(str, pat)
>     @str = str
>     @pat = pat
>   end
>   
>   def each(&block)
>     @str.scan(@pat, &block)
>   end
> end
> 
> scanner = StringScanner.new("a1b2c3", /[a-z][0-9]/)
> scanner.my_each_with_index {|x| ... }

なるほど、/[a-z][0-9]/ じゃなくて /([a-z])([0-9])/ みたいにした
ときですね。またまた一本とられました。というか、どうしても前田さ
んの主張で分からないことがあったんですが今これで理解できました。

もっと早く分かるべきだった。つーか、何でもっとこの例を早く出して
くれなかったのー、と開き直ったりして、、(^^;;;

この StringScanner#my_each_with_index は Stirng#scan に依存する
A-L(Array-List) sensitive(今作った造語)なメソッドなわけですね。
この例は、ユーザーが意識しなくてもインクルードするライブラリが
A-L sensitive なのでユーザーの作るメソッドが A-L sensitive に
なってしまった例です。

[ruby-dev:3789] で前田さんはこう言いました。

>僕が考えていたのは、基本的に配列とリストを区別しないというモデル
>が前提で|*x|の時だけ区別することになると、yield([1, 2])として複数の
>値を渡すつもりだった人にとっては、上のeach_with_indexのような
>場合に挙動が変わってきて困惑することになるし、逆に受け取る方として
>はリストではなく配列を受け取ったとしても、yieldした側が複数の値と
>して渡したかったのかもしれないというリスクがつきまとってしまう
>ということです。

で、私は scan の利用者は scan の仕様について良く知っているから、そ
のリスクというものは無いのではないか?という風に反論したのですが、
これは考えが足りなかったと思います。今回の例の様に scan の仕様に詳
しくない StringScanner のユーザーあるいは StringScanner の作者とい
うのはありえるわけですね。その人にとっっては StringScanner の
my_each_with_index の挙動は「やって見ないと分からない」と感じられる
でしょう。

そして、その状態を避けるために、今まで scan などのブロックパラメー
タに配列を渡していたイテレータに対する対処の仕方としては、次の様な
ものが考えられます。

(A)今まで通り配列を渡す。

これはせっかくリストを渡せるようになったのに、(前田さんが言っ
ていましたが)そもそも何のためのモデル変更か意義が疑われてもし
かたがない。(まあそれでもいいや、というのが私の意見だった。)

(B)Hash#each はリストにするが String#scan などは配列のまま。

マニュアルで全てきちんとリストを渡しているのか配列を渡しているの
か明示しないと利用者が困る。とても似ているのに異なる、そこが好ま
しくない。

(C)複数の値という事を意図して配列を渡していたものは全てリス
      トに変える。

やはりこれも前田さんが [ruby-dev:3789] で、

(私の案に従うならば)
>少なくとも標準ライブラリについては、配列で複数の値を渡すことを
>期待したコードをすべて書き直す必要があるように思います。

と指摘したまさにその通りです。


で、現在の私の提案は(C)です。なぜなら、変更が必要な標準ライブラ
リのメソッドは (Hash|Dbm|ENV).(each|delete_if?) と String#scan だ
けみたいだからです。他にもあるかもしれないけどそう多くはないのでやっ
てしまえ、という事です。非互換性もほとんどない。RAA も気になります
が。

どうでしょうか?


Enumerable の仕様の方に話を移します。

> > (あ)
> >   def collect
> >     ary = []
> >     each { |x|
> >       ary.push yield(x)
> >     }
> >     ary
> >   end
> > 
> > という定義ですが、List 方式が導入されたらやはり
> > 
> > (い)
> >   def collect
> >     ary = []
> >     each { |*x|
> >       ary.push yield(*x)
> >     }
> >     ary
> >   end
> 
> Cだと(い)は書きにくいので、Cレベルでは直接Listが見えるようにした
> 方がいいかもしれませんね。
> そうすると(あ)の書き方で(い)と同じ意味になると思います。

C のレベルで List が見えるのはいいと思います。(あくまで Ruby の
レベルでの言葉遣いをすることにすると、、) Enumerable#collect な
どは(い)の動作にしてしまうのが自然なのですね。それならそれがい
い思います。

というわけで、Enumerable のイテレータは each_with_index 以外は
 each に関して A-L sensitive なものすなわち |*x| で受けて *x と
送る様なものに書き換える、ということでいいでしょうか?

[ruby-list:11043] の enumerable.rb を見ながら考えるに、find_all
はちょっと注意が必要かな。

#しかしこれだけ議論して、現実に役に立つ A-L sensitive なメソッ
#ドって my_each_with_index ぐらいしか出てないのが恐ろしい。:-)

In This Thread