From: "NARUSE, Yui" Date: 2008-08-30T08:16:21+09:00 Subject: [ruby-dev:36049] Re: TypeError from Encoding.compatible? (r18920) 成瀬です。 Yukihiro Matsumoto wrote: > まつもと ゆきひろです > > r18920でEncoding.compatible?がTypeErrorをあげるようになりま > したが、これが引数チェックなしにBUILTIN_TYPE()を使っているた > め、test_m17n.rbが落ちます。 > もし、例外をあげるべきだと言うのであれば、BUILTIN_TYPE()では > なく、TYPE()を使うべきでしょう。 この 2 つはとりあえず修正しました。 > 今までのようにそもそもencodingの対象 > ではない時nil、compatibleでない時false、compatibleな時trueの > 方が良いように思います。 そのような仕様は初耳です。 * call-seq: * Encoding.compatible?(str1, str2) => enc or nil * * Checks the compatibility of two strings. * If they are compatible, means concatenatable, * returns an encoding which the concatinated string will be. * If they are not compatible, nil is returned. encoding.c の rdoc より r18920 以前では以下の通りでした。 * encodingの対象ではない時 nil * compatible でない時も nil * compatible な時はどこにおいて compatible かに応じて enc # Encoding.compatible?("\u3042", "hoge") #=> Encoding::UTF_8 # 等の結果が欲しいので enc である必要がある # 言い換えれば、2 つの str を結合した時の encoding が返る そして、r18920 で、 * encodingの対象ではない時 TypeError * compatible でない時も nil * compatible な時は enc > ですが、そもそもcompatible?が例外をあげる必要があるのでしょ > うか。コンパチかどうかチェックしたいだけなのに例外が上がるの > は使いにくい気がします。 もともと、Encoding.compatible? の引数に encoding を与えると 期待したとおりに動作しないというのがありまして、 > Encoding.compatible?(Encoding::UTF_8, Encoding::US_ASCII) => # # rb_enc_get_index() は encoding を対象としないため このような誤解を招く動作をするよりは、 潔く例外を出してくれた方がいいと考えました。 # Encoding.compatible? が encoding を取れるようにするべき、 # という案については現在思案中 まつもとさんの仰る仕様ならば一貫性があるのでよいと思うのですが、 現行の仕様では compatible な時に enc を返す以上、 false と nil で区別という方法が使いづらいのがネックでしょうか。 enc / false / nil でもいいのかなぁ・・・。 r18920 の意図は Encoding.compatible? が対応しているオブジェクトと、 対応していないオブジェクトをはっきりわけることだったので、 例外を出すことにこだわりはないのですが・・・。 -- NARUSE, Yui