[#17276] blocks and local variables — Takaaki Tateishi <ttate@...>

立石です.

127 messages 2002/06/02
[#17283] Re: blocks and local variables — matz@... (Yukihiro Matsumoto) 2002/06/02

まつもと ゆきひろです

[#17294] Re: blocks and local variables — Takaaki Tateishi <ttate@...> 2002/06/03

At Mon, 3 Jun 2002 06:26:56 +0900,

[#17298] Re: blocks and local variables — matz@... (Yukihiro Matsumoto) 2002/06/03

まつもと ゆきひろです

[#17332] Re: blocks and local variables — nobu.nakada@... 2002/06/06

なかだです。

[#17336] Re: blocks and local variables — matz@... (Yukihiro Matsumoto) 2002/06/07

まつもと ゆきひろです

[#17337] Re: blocks and local variables — nobu.nakada@... 2002/06/07

なかだです。

[#17338] Re: blocks and local variables — matz@... (Yukihiro Matsumoto) 2002/06/07

まつもと ゆきひろです

[#17339] Re: blocks and local variables — Tanaka Akira <akr@...17n.org> 2002/06/07

In article <1023423387.175193.27185.nullmailer@picachu.netlab.jp>,

[#17347] Re: blocks and local variables — Takaaki Tateishi <ttate@...> 2002/06/07

At Fri, 7 Jun 2002 13:23:37 +0900,

[#17352] Re: blocks and local variables — matz@... (Yukihiro Matsumoto) 2002/06/07

まつもと ゆきひろです

[#17404] Re: blocks and local variables — "K.Kosako" <kosako@...> 2002/06/12

Yukihiro Matsumotoさんの

[#17411] Re: blocks and local variables — matz@... (Yukihiro Matsumoto) 2002/06/12

まつもと ゆきひろです

[#17518] Re: blocks and local variables — "K.Kosako" <kosako@...> 2002/06/19

Yukihiro Matsumotoさんの

[#17521] Re: blocks and local variables — nobu.nakada@... 2002/06/19

なかだです。

[#17524] Re: blocks and local variables — "K.Kosako" <kosako@...> 2002/06/19

nobu.nakada@nifty.ne.jpさんの

[#17528] Re: blocks and local variables — matz@... (Yukihiro Matsumoto) 2002/06/20

まつもと ゆきひろです

[#17459] Re: blocks and local variables — NISHIO Mizuho <gha@...> 2002/06/16

どうも西尾です。

[#17460] Re: blocks and local variables — nobu.nakada@... 2002/06/16

なかだです。

[#17462] Re: blocks and local variables — Takaaki Tateishi <ttate@...> 2002/06/16

At Sun, 16 Jun 2002 10:40:40 +0900,

[#17464] Re: blocks and local variables — nobu.nakada@... 2002/06/16

なかだです。

[#17367] Ruby bcc32 on Win32 版のコミットについて — 小西 弘将 <konishih@...6.so-net.ne.jp>

小西 弘将です。

17 messages 2002/06/10
[#17368] Re: Ruby bcc32 on Win32 版のコミットについて — matz@... (Yukihiro Matsumoto) 2002/06/10

まつもと ゆきひろです

[#17369] Re: Ruby bcc32 on Win32 版のコミットについて — 小西 弘将 <konishih@...6.so-net.ne.jp> 2002/06/11

 小西 弘将です。

[#17370] Re: Ruby bcc32 on Win32 版のコミットについて — "U.Nakamura" <usa@...> 2002/06/11

こんにちは、なかむら(う)です。

[#17421] broken string when unterminated "#{". — WATANABE Hirofumi <eban@...>

わたなべです。

43 messages 2002/06/13
[#17422] Re: broken string when unterminated "#{". — matz@... (Yukihiro Matsumoto) 2002/06/13

まつもと ゆきひろです

[#17423] Re: broken string when unterminated "#{". — Tanaka Akira <akr@...17n.org> 2002/06/13

In article <1023943870.232495.9282.nullmailer@picachu.netlab.jp>,

[#17425] Re: broken string when unterminated "#{". — matz@... (Yukihiro Matsumoto) 2002/06/13

まつもと ゆきひろです

[#17426] Re: broken string when unterminated "#{". — Tanaka Akira <akr@...17n.org> 2002/06/13

In article <1023945463.297286.10112.nullmailer@picachu.netlab.jp>,

[#17439] Re: broken string when unterminated "#{". — nobu.nakada@... 2002/06/13

なかだです。

[#17440] Re: broken string when unterminated "#{". — matz@... (Yukihiro Matsumoto) 2002/06/13

まつもと ゆきひろです

[#17442] Re: broken string when unterminated "#{". — Tanaka Akira <akr@...17n.org> 2002/06/14

In article <1023987024.717469.15784.nullmailer@picachu.netlab.jp>,

[#17530] Re: broken string when unterminated "#{". — nobu.nakada@... 2002/06/21

なかだです。

[#17532] Re: broken string when unterminated "#{". — matz@... (Yukihiro Matsumoto) 2002/06/21

まつもと ゆきひろです

[#17539] Re: broken string when unterminated "#{". — Tanaka Akira <akr@...17n.org> 2002/06/21

In article <1024642728.541545.22623.nullmailer@picachu.netlab.jp>,

[#17540] Re: broken string when unterminated "#{". — matz@... (Yukihiro Matsumoto) 2002/06/21

まつもと ゆきひろです

[#17541] Re: broken string when unterminated "#{". — nobu.nakada@... 2002/06/21

なかだです。

[#17430] return value from methods of Array's subclass — "Shin'ya Adzumi" <adzumi@...>

あづみです。

12 messages 2002/06/13

[#17446] ternary operator and char literal (Re: parse error with `true || break ? 0 : 1' (PR#261)) — nobu.nakada@...

なかだです。

13 messages 2002/06/15
[#17454] Re: ternary operator and char literal (Re: parse error with `true || break ? 0 : 1' (PR#261)) — matz@... (Yukihiro Matsumoto) 2002/06/15

まつもと ゆきひろです

[#17461] Re: ternary operator and char literal (Re: parse error with `true || break ? 0 : 1' (PR#261)) — nobu.nakada@... 2002/06/16

なかだです。

[#17513] __END__ in literal — nobu.nakada@...

なかだです。

17 messages 2002/06/18
[#17516] Re: __END__ in literal — matz@... (Yukihiro Matsumoto) 2002/06/18

まつもと ゆきひろです

[ruby-dev:17267] Re: [ruby-list:35305] Re: ((1.2)..(3.4)).to_a

From: siena@... (Siena.)
Date: 2002-06-01 17:34:07 UTC
List: ruby-dev #17267
Siena. です。

かなり悩みましたが、自分の中では少し整理できたように思いますので。

▼ [ruby-dev:17228] < Yukihiro Matsumoto さん

[ruby-list:35279] で Ruby は大クラス主義という御指摘もありましたが、
それを踏まえても、やはり Range に連続・離散区間の両方を扱わせるのは
避けたいという見解に (今のところ) 落ち着いています。

とりあえず、そう考える理由を挙げておきたいと思います。

》ちょっと考えてみました。で、結局問題があるのは
》
》  member?, include?
》  step, eachおよびeachを元にしたEnumerableメソッド

Enumerable のメソッドは、Enumerable としての挙動をとって欲しいです。
クラス単体で見た場合に Enumerable と異なる挙動であった方が自然であっても、
Enumerable であるとみなして扱う時に Range を特別扱いしないとなりません。
Enumerable その存在が大きいため、例外的なものがあると抽象レベルで
扱う事を難しくしてしまいます。更に Range は組み込みクラスなので、
余計に整合性を損なってしまうのではないかと危惧します。

例えば、Enumerable なオブジェクト群 [ e_1, e_2, ... ] があった時に、
あるオブジェクト val で include? val == true となる e_i において
each するといった場合などに、含んでいると判定されたのにもかかわらず
each 中に出現しないという状況が発生してします。これを避けるために、
Range のためだけに to_a.include? val とするのも本末転倒と感じます。

連続区間としてのメソッドを Enumerable のメソッドとは異なる
名前で定義する事も、選択肢としてはありえます。しかしこの場合、
Enumerable のメソッド名が汎用的で連続区間としてのメソッドの
名前と競合しやすいため、不自然/冗長な名前になる、似た名前の
異なるメソッドが並存する、などの問題が出てしまうと思います。
これが自然に解決できるようならば一つのクラスにまとめても
良いですが、それは非常に困難ではないかと想像しています。

》  * member?, include?
》
》    Numericであるか、succが定義されていなければ範囲によるチェッ
》    クを行う。succが定義されていれば繰り返してみてその要素が
》    あるかないかをチェック。

というわけですので、Numeric であっても、離散区間
(離散集合) としてのメンバシップ判定を行なって欲しいです。
そうでないならば、Range は Enumerable と似て非なる
インターフェイスを持つ事になり、好ましくないと思います。


上の問題と刻み幅を持たせるという事は独立に
考えられるので、こちらは別途考えたいと思います。
ちょっとしつこいようで申し訳ないのですが、
もう少しお付き合いいただけたら幸いです。
以下、便宜上、刻み幅を diff (デフォルトは 1) と表記します。

》  * step, eachおよびeachを元にしたEnumerableメソッド
》
》    eachはsuccが定義されていなければTypeError例外(だから
》    Float のRangeには使えない。これにより全部のEnumerableメ
》    ソッドは要素がsuccを持つ必要がある。
》
》    stepはNumericならstepを毎回+する(Floatでは誤差が蓄積する
》    が、ここでは無視)。それ以外ならsuccを使って定義する。

Range#each で、first と diff の加算が可能であれば diff ずつ進み、
そうでなければ diff (但し、FixNum) 回 succ しつつ進む、という
挙動は、これらの判定ができるならば不自然な定義とは思えませんので、
導入を検討していただきたく思います。これらの判定は、上記の
まつもとさん提案のものと同様 (or 改善版) で良いと考えています。

また、Range#each は Range#step( 1 ) 相当とみなされると思います。
つまり、Range#step( n ) は、first と diff の加算が可能であれば
diff * n ずつ進み、そうでなければ diff * n 回 succ しつつ進む、
という挙動で定義できると考えています。


改めて次を提案したいと思います。
* 純粋に連続区間を扱うために Interval といったクラスを
  導入して、連続・離散区間を扱うクラスを分ける
* Range は刻み幅 (デフォルトは従来相当の 1) を持つ範囲として拡張する
* Range#interval, Interval#range( diff ) といった
  メソッドで互いを抽出できるようにする

Range#=== を離散区間としてのメンバシップ判定に従わせるか、
従来との互換性を考えて連続区間としてのメンバシップ判定に
従わせるかは、議論のあるところだと思います。
上の提案の場合は、少なくとも、従来の Range#=== は
Range#interval.=== (書き方が変 ^^;) 相当とみなせます。

この提案は現実的ではない、もしくは Ruby の方針に合わないでしょうか。
Interval 相当はユーザライブラリとするのでも良いですが、
少なくとも Range は上記のようになっていて欲しいと思います。

# また長くなってしまった... (--;

---
Siena. <mailto:siena@cr.chiba-u.ac.jp>

In This Thread