[ruby-dev:41496] Re: [Feature #3328] Kernel#p outputs as default_internal encoding, and so on

樽家です。

> |> 同様な処理といいながらなぜ新しい API を追加するんですか。
> |
> |Featureなので、私的に思い切ってどう処理したら理想的だろうと考えた結果です。
> |同様な処理=inspect_encodeですが、結局Symbol型やRegexp型に限らず
> |必要になりそうなので分離したいと思いました。
>
> 結論がないので申し訳ないのですが、encoding処理の理想は空気の
> ように見えないことで、いつかの将来Unicodeが世界制覇した時に実
> 現されるのだと思います(実現するのであれば)。で、仮にこのAPIが
> その頃まで残ったとすると、盲腸のように不要なものになることが
> 予想されます。それはAPIデザインとして筋が悪いのではないでしょ
> うか。

encoding処理の理想は空気のように見えないというのは確かに素晴らしいです。
私自身Encodingがうまく理解出来なくて、1.9に以降するのを本当に大分遅らせましたし、仕事で使っているのはいまだに1.8系という体たらくです。
ただ少なくとも、今すぐ実現するものではないでしょうし、そのころまでそのAPIが残ったとするのには無理が無いでしょうか？
少なくともString#encodeが消えるときには一緒に消えたら良いと思います。
当面はencodingに煩わされると仮定した現状での理想です。

# それとは別にまつもとさんも結論がないと言われている「空気のように見えない」は確かに欲しいですが、残念ながらこれといった提案が思い浮かばず今のところ出来ていません。

現在のString#inspectは
1)不可視文字(制御文字)の可視化である所のエスケープと、
2)元のエンコードが、表示エンコードと違う場合に強引に表示エンコードに合わせる処理(\x{xxxx}や\uxxxxへの置き換え)
を行っていますが、2)の元のエンコードが表示エンコードと違う場合に強引に表示エンコードに合わせる処理はSymbolやRegexp,Array,Hashで必要なように割と汎用的に欲しい機能です。
またpがユーザー定義のinspectを呼ぶ場合にも処理させたい機能だと思います。

おそらくEncoding::Converter#primitive_convertを使えば何とか同じ機能を実現できるんでしょうし、
これらの内部で使うだけにして非公開する という判断は先のメールに書いたように、それはそれでありです。


ただし、ユーザーがArrayの様な、内部でinspectを呼ぶクラスのinspcetを書くときにはEncodingに互換性が無いと起こられる
可能性がある限りは必要な変換ですし、公開した方がうれしい人が多いのではないと思います。

失敗せずになんらかしらの形で対象encodingに変換してくれる簡便なAPIが無いという現状のencoding環境はstrictですが、
プログラムしていて主にデバックで辛いです。

-- 
樽家昌也(Masaya TARUI)
No Tool,No Life.