[#17276] blocks and local variables — Takaaki Tateishi <ttate@...>
立石です.
まつもと ゆきひろです
At Mon, 3 Jun 2002 06:26:56 +0900,
まつもと ゆきひろです
なかだです。
なかだです。
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
In article <1023423387.175193.27185.nullmailer@picachu.netlab.jp>,
まつもと ゆきひろです
Yukihiro Matsumotoさんの
まつもと ゆきひろです
なかだです。
前田です。
At Fri, 7 Jun 2002 13:23:37 +0900,
まつもと ゆきひろです
Yukihiro Matsumotoさんの
まつもと ゆきひろです
Yukihiro Matsumotoさんの
なかだです。
nobu.nakada@nifty.ne.jpさんの
まつもと ゆきひろです
Yukihiro Matsumotoさんの
まつもと ゆきひろです
Yukihiro Matsumotoさんの
原です。
原です。
なかだです。
原です。
どうも西尾です。
なかだです。
At Sun, 16 Jun 2002 10:40:40 +0900,
なかだです。
At Sun, 16 Jun 2002 12:24:00 +0900,
なかだです。
At Sun, 16 Jun 2002 16:57:13 +0900,
なかだです。
どうも西尾です。
まつもと ゆきひろです
[#17315] Re: mswin32 での config.status の自動生成 — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
[#17327] irb 0.9 alpha — keiju@... (Keiju ISHITSUKA)
けいじゅ@日本ラショナルソフトウェアです.
けいじゅ@日本ラショナルソフトウェアです.
けいじゅ@日本ラショナルソフトウェアです.
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
[#17367] Ruby bcc32 on Win32 版のコミットについて — 小西 弘将 <konishih@...6.so-net.ne.jp>
小西 弘将です。
まつもと ゆきひろです
小西 弘将です。
こんにちは、なかむら(う)です。
小西 弘将です。
[#17384] avoid VC++ warnings — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
[#17392] [mswin32] exporting needless string literal — Tietew <tietew-ml-ruby-dev@...>
なかだです。
[#17393] [mswin32] static linked exts — Tietew <tietew-ml-ruby-dev@...>
[#17421] broken string when unterminated "#{". — WATANABE Hirofumi <eban@...>
わたなべです。
まつもと ゆきひろです
わたなべです。
In article <1023943870.232495.9282.nullmailer@picachu.netlab.jp>,
まつもと ゆきひろです
In article <1023945463.297286.10112.nullmailer@picachu.netlab.jp>,
なかだです。
まつもと ゆきひろです
In article <1023987024.717469.15784.nullmailer@picachu.netlab.jp>,
なかだです。
まつもと ゆきひろです
In article <1024642728.541545.22623.nullmailer@picachu.netlab.jp>,
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
なかだです。
In article <200206220646.g5M6kPY04591@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
In article <200206230606.g5N66RY15961@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
まつもと ゆきひろです
In article <1024667757.665595.25808.nullmailer@picachu.netlab.jp>,
まつもと ゆきひろです
In article <1024750854.951300.30306.nullmailer@picachu.netlab.jp>,
まつもと ゆきひろです
In article <1024887804.945188.6501.nullmailer@picachu.netlab.jp>,
まつもと ゆきひろです
In article <1024895400.920419.6574.nullmailer@picachu.netlab.jp>,
[#17430] return value from methods of Array's subclass — "Shin'ya Adzumi" <adzumi@...>
あづみです。
あづみです。
まつもと ゆきひろです
あづみです。
[#17446] ternary operator and char literal (Re: parse error with `true || break ? 0 : 1' (PR#261)) — nobu.nakada@...
なかだです。
まつもと ゆきひろです
なかだです。
In article <200206160226.g5G2QO228336@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
In article <200206160749.g5G7nI231269@sharui.nakada.kanuma.tochigi.jp>,
まつもと ゆきひろです
[#17471] break from proc-closure — m_seki@...
まつもと ゆきひろです
In article <1033663928.287610.25914.nullmailer@picachu.netlab.jp>,
なかだです。
[#17475] String#crypt always returns tainted string — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#17513] __END__ in literal — nobu.nakada@...
なかだです。
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
なかだです。
In article <200206211121.g5LBLl211556@sharui.nakada.kanuma.tochigi.jp>,
[#17579] Re: [ruby-cvs] ruby: * dln.c: remark definition rb_loaderror(). — WATANABE Hirofumi <eban@...>
わたなべです。
[ruby-dev:17280] Re: [ruby-list:35305] Re: ((1.2)..(3.4)).to_a
Siena. です。 [ruby-dev:17273] の静的型を想定するのは Ruby 的ではない、というのを受けて。 ▼ [ruby-dev:17268] < Yukihiro Matsumoto さん 》|単に + があるだけでは駄目、というのは、succ が存在しなくて 》|+ が存在するという場合に、+ が算術的な意味で定義されてないと 》|期待するように動作しないから、という理解で良いですよね。 》|現状で、適切なルールを定めるのは困難ではないかと思います。 》 》そうですね。だから思いつかないわけですけど。 新しくなんらかの約束を設けない限り、思い付くのは無理ではないでしょうか。 # 個人的な見解は、「困難」から「無理」に変わりました ^^; メソッド名が判断の根拠にならず、+ が算術演算であるか否かなどを調べる ためのメソッドもなく、共通の上位クラス / Mixin モジュールも想定できず、 静的型を前提とした考え方も Ruby 的ではない、という現状では。 ▼ [ruby-dev:17265] < Siena. 》あるいは、算術的な意味での + ならば、__add__ というメソッドを 》定義して、alias :+ :__add__ とするように約束を設けるとか。 というのはモジュール分割ではない案ですが、まとめて却下でしょうか。 》|算術的な意味での演算であるかを確認できるようにできないでしょうか。 》| 》|とりあえず、「Numeric ならば」というのは保証にならないので、例えば 》|Arithmetic モジュールを導入し、必要に応じて include する事にして、 》|Numeric 以外でも算術を保証できるようにするとかいうのを思い付きます。 》 》「Numericならば算術+がある」のは保証できると思います。 はい。おっしゃる通りです。 意図が伝わりにくい書き方だったかもしれません。 対象としたいクラスが Numeric を継承しているものとは限らないので、 「Numeric であること」だけを対象とみなせるクラスである事の 必要十分条件とするのは適切ではない (だから、より一般的に 適用できる条件を設けてはどうか)、という事を意図していました。 # というのは伝わっている上でのご指摘と思いますが、念のため補足 ^^; 》Arithmeticモジュールの導入については、モジュールに分割してい 》くのはあんまり趣味じゃないです。それに Time が Arithmetic か 》と問われると「それは違うだろう」という気持ちになります。 この分割案も静的型を想定した話ですので、取り下げたいと思います。 Arithmetic というのは、あくまでも「例えば」ですので、 より適切なものを別途考えるというつもりでいました。 単に思い浮かばなかっただけです ^^; 》|# Numeric って、実質的には実数の部分集合だけです? 》 》ComplexもNumericのサブクラスですが。Numeric#stepの場合には あ、そうですね。忘れていました ^^; 実数あらため複素数も含めた 直感的に「数」と扱われている集合を表す事を目的としているのか、 そうではないもっと抽象的なこれこれの条件を満たす集合 (*) を 表す事を目的としているのかというのが、ちょっと気になったので。 普通に考えると前者でしょうから、一般的には、ある条件を満たす (例えば、+ が代数的な「加法」として定義されている) クラスは Numeric のサブクラスである、などの仮定はできないのだろうなあ と、上記の「Numeric ならば」云々のところで思っての疑問でした。 独り言にまで付き合ってくださってありがとうございます。 (*) 例えば、体や環、あるいはもっとくだけた条件付けでも構いません --- Siena. <mailto:siena@cr.chiba-u.ac.jp>