[#20127] protected_instance_methods(true) — Shin-ichiro HARA <sinara@...>
原です。
4 messages
2003/05/01
[#20163] Numeric#step — Koji Arai <JCA02266@...>
新井です。
13 messages
2003/05/05
[#20165] Re: Numeric#step
— Minero Aoki <aamine@...>
2003/05/05
青木です。
[#20167] Re: Numeric#step
— Koji Arai <JCA02266@...>
2003/05/05
新井です。
[#20169] Re: Numeric#step
— Minero Aoki <aamine@...>
2003/05/05
青木です。
[#20171] Re: Numeric#step
— Koji Arai <JCA02266@...>
2003/05/05
新井です。
[#20172] Re: Numeric#step
— Masahiro TANAKA <masa@...>
2003/05/06
At Tue, 6 May 2003 02:55:54 +0900,
[#20197] ARGF.filename — Koji Arai <JCA02266@...>
新井です。
6 messages
2003/05/17
[#20209] /()*\1/ =~ "" — Tanaka Akira <akr@...17n.org>
元ネタは BTS および Matzにっきなのですが、Matzにっきの調子が悪くてつっ
5 messages
2003/05/19
[#20227] dyna_vars problem? — Tanaka Akira <akr@...17n.org>
しばらく前から、稀に Ruby が core を吐くという問題を追いかけているので
15 messages
2003/05/19
[#20234] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/19
まつもと ゆきひろです
[#20236] Re: dyna_vars problem?
— Tanaka Akira <akr@...17n.org>
2003/05/19
In article <1053363181.529491.30320.nullmailer@picachu.netlab.jp>,
[#20245] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/20
まつもと ゆきひろです
[#20248] Re: dyna_vars problem?
— Tanaka Akira <akr@...17n.org>
2003/05/20
In article <1053422521.786672.22712.nullmailer@picachu.netlab.jp>,
[#20250] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/20
まつもと ゆきひろです
[#20251] Re: dyna_vars problem?
— Tanaka Akira <akr@...17n.org>
2003/05/20
In article <1053424909.383731.24667.nullmailer@picachu.netlab.jp>,
[#20255] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/20
まつもと ゆきひろです
[#20268] splat restary — nobu.nakada@...
なかだです。
5 messages
2003/05/21
[#20303] [Oniguruma] possessive quantifier — kkosako@...
強欲な繰り返し演算子を実装してみたんですが、
1 message
2003/05/28
[#20307] [Oniguruma] intersection of char class — kkosako@...
Javaの正規表現で実現されている
4 messages
2003/05/30
[ruby-dev:20284] Re: compare between String and Exception
From:
Tanaka Akira <akr@...17n.org>
Date:
2003-05-23 14:03:20 UTC
List:
ruby-dev #20284
In article <1053418411.495451.20782.nullmailer@picachu.netlab.jp>,
matz@ruby-lang.org (Yukihiro Matsumoto) writes:
> 要するに
>
> * <=>が成立しないケースは厳密には2種類ある
> + そもそも型が合わない
> + 型は合うが順序関係が成立しない
> * これらを区別するため、前者は例外、後者はnilになるべきだ。
>
> ということですよね。
はい。
> 私の考えとしては
>
> * 2種類を区別する必要があるのか
>
> ほとんどの場合、ユーザが関心あるのは、比較できるかできな
> いかだけ。
同意できません。ほとんどの場合、ユーザは比較できるときのことしか関心を
持たないように思います。
したがって、比較できないときに対処するコードが少なくなるような仕様が良
いと思います。
> 「情報は多い方が良い」とは限らない。むしろ場合分けが多く
> なるかも。
反論します。普通のプログラムではこの例外はバグを示すため、rescue する
必要はありません。つまり、場合分けは多くなりません。
そして、例外は nil よりもバグを早期に検出します。nil を返した場合には
問題を検出するにはユーザが自分で検査しなければいけませんが、例外ならな
にも書かないで検出されます。
もちろん、多くの場合、正しいプログラムは比較できないものを比較したりは
しないので、これはユーザがバグを追いかけているといった状況の話です。
例外にしておけば、なにもしなくても検査が入っている状況になり、ユーザは
無用にプログラムを疑わなくて済みます。
まぁ、<=> を直接使うのは主に sort のブロックで、その場合は nil を返せ
ば例外になるから、この理由はちょっと弱いかもしれませんが。
> 半順序関係はクラス/モジュールだけだし、理由はともかく順
> 序関係が成立しないのだから、差別する必要はない。
反論します。この情報の欠落は反対称律の実現を厄介にします。
% ruby -rdelegate -e '
class C; end
class D; end
c = SimpleDelegator.new(C)
p c < D
p D < c
'
nil
-e:6:in `<': compared with non class/module (TypeError)
from -e:6
例外を出すべきかどうかという条件判断を <=> がしてくれないため、その判
断を <, <=, >, >= に埋め込む必要があります。そして、<, <=, >, >= を
<=> の呼び出しによって実現するのであれば、比較可能なクラスは相互に相手
を知っていなければなりません。その結果、比較可能な後からクラスが増える
状況を扱うのが困難になります。
もちろん、組み込みの中で半順序なのは Module だけで、Module と比較可能
なクラスを後から付け加えるというのは非現実的ですが、<=> というメソッド
の使いかたの範を示すという意味でよろしくないと思います。
> * ないとすると、成立しない場合には、例外かnilか
>
> 例外だとエラーメッセージに内部利用されている<=>が登場す
> ることになる
これはまったく考えていませんでした。なるほど。
> これを避けるにはコストのかかる例外補足が必要
>
> => nilの方が良い
>
> ということで、現状維持を推します。
>
> nilから適切なメッセージを持つ例外に変換する方が、例外を補足
> して適切なメッセージで再発生させるのより安いというのも動機の
> 一つです。
効率に関しては反論しません。
たしかに、上で述べたような利点を実現するのに引き合うかどうか、というバ
ランスを考慮する必要はあると思います。
--
[田中 哲][たなか あきら][Tanaka Akira]