ささだです。

 最新版の HEAD で p "abc" すると、

Exception `NoMethodError' at mkmonthpage.rb:3 - undefined method `to_ary' for "abc":String

 こんなエラーを ruby -d で起動すると吐くようになりました。
(デバッグ用の、フックされた例外も表示する機能)


これは、

* object.c (convert_type): [ruby-core:03845]

 の変更だと思うのですが、いつも ruby -d で実行している私には
このエラー表示は少々鬱陶しいと思えます。

 そこで、ruby-core の該当部分への代替案を考えてみました。
日本語で失礼します。-d 好きの私としては、検討して頂ければ
嬉しいです。


現状:

 とりあえず変換メソッド(to_ary など)を rb_funcall_rescue で
呼んでみる。


代替案:

1. rb_funcall(respond_to?)

 コストの問題から却下、とまつもとさん([ruby-core:03845])


2. rb_respond_to() を呼べるなら呼んでみる

 対象オブジェクトが respond_to? を上書きしているか調べる。

 具体的には、対象オブジェクトに対してメソッド検索をかけて、
それが Object#respond_to? ならば rb_respond_to() を呼ぶ。

(2.1)
 そうでなければ、rb_funcall(respond_to?) を呼ぶ。

(2.2)
 そうでなければ、rb_funcall_rescue(convert_method) を呼ぶ。


3. rb_respond_to の定義を変える

 rb_respond_to() 実行時、2. と同様に respond_to? が再定義
されているか調べる。再定義されていれば、rb_funcall(respond_to?)、
そうでなければ従来動作。

 でも、Object#respond_to? でもこのチェックを入れるのは不毛で
すね。二つに分ければいいのかな。



・rb_respond_to を用いる案の問題点

a. to_ary は method_missing などできちんとやるんだけど、
   respond_to? を再定義していなかった場合

>再定義しない奴が悪い


b. respond_to? を method_missing などできちんとやる
(再定義されているかの判断が不可能)

>respond_to? くらいきちんと再定義しろよ


・rb_respond_to を用いる案のメリット

i. 変換メソッドがなかった場合のパフォーマンス向上

ii. -d で鬱陶しくない



 別に -d で鬱陶しくしなくするためだけには、暗黙の変換で利用
されるメソッドを Object で定義すればいいんですかね。それがい
いか悪いかはちょっとわかりません。

-- 
// SASADA Koichi at atdot dot net
//