[ruby-dev:16943] Iconv

In article <[e-mail]>,
  [e-mail] writes:

> Iconv.iconvで複数のStringを渡されたときに、エラーになったString
> 以降がそのまま収められるようになってます。で、最初failedはやめ
> ちゃおうかと思ったんですが…。

理解しました。「以降」というところがわかっていませんでした。ふむ。

えぇと、理解した第一印象は必要以上に複雑なのではないかというものです。
Iconv.iconv という一番複雑なところの都合で通常の用途が面倒になってしま
うのは気に入りません。CGI#[] が Array を返すのに似た匂いがするといいま
すか。そもそも Iconv.iconv はいちいちインスタンスを生成せずに済む簡易
的な使用法として位置付けられている(と思う)のに、それが面倒臭さの原因に
なっているところが引っかかります。

しかも、(ちゃんとソースを読んでいるわけではないので推測になりますが)
E2BIG な時には自動的に iconv(3) が繰り返し呼ぶことによって出力バッファ
を抽象化していることを考えると、渡した文字列のそれぞれと iconv(3) の呼
び出しが一対一で対応するわけでもなく、何が起きたのかを完全に把握できる
わけでもなさそうです。まぁ、これは Iconv.iconv だけではなくて
Iconv#iconv でもそうなのでしょうが。

思うに、むしろ Iconv.iconv を単純化するか、捨てるかした方がいいのでは
ないかという気がします。たとえば、Iconv.iconv は廃止して、

def Iconv.conv(to, from, str, dont_shift_to_init_at_last=false)
  Iconv.open(to, from) {|cd|
    result = ''
    result = cd.iconv(str)
    result << cd.iconv(nil) unless dont_shift_to_init_at_last
    result 
  }
end

というようなのを新設するとか。

どうせ、文字列ひとつをともかく難しいことは考えずに変換したいという場合
が一番多いでしょうから、その文字列を単純に渡せば変換して terminate も
してくれた文字列が返ってくる、というインターフェースのがお気軽でいいの
ではないかと思います。

互換性を考えないならいきなりこれを Iconv.iconv にするというのもありか
も知れません。

で、Iconv::Failure#source は Iconv#iconv の第一引数をそのまま保持する
とします。そうすれば、Iconv.conv で例外が発生しても、Iconv#iconv の 2
回の呼び出しのうちどちらで発生したのかはわかります。

複数の文字列に分けて呼び出したいっていうのはどんな場合がありますかね?
文字が別れていた時に Iconv::InvalidCharacter が発生して欲しい場合?
実行効率? 他にはなにがあるでしょう?

いずれにせよ、ちゃんとインスタンスを生成して変換すればだいたい問題ない
と思うので、簡易インターフェースに多くは求めないのがいいのではないかと
思います。

> 初期ステートに戻すシークェンスを返す機能があるんだから、初期ス
> テートから現在のステートに移行するシークェンスを返すというのも
> あってよさそうな気がしてきました。

そうかもしれません。まぁ、これは標準の話なので Ruby 側でどうこうできる
ことじゃありませんが。

> でもiconv_tは複製されないから結局同じですよ。たぶん、どこかで
> closed iconv (ArgumentError)といわれるのがオチじゃないかと。

ちっ。

> エラーのときにyieldするというのはどうかなとか、今ふと思ったんで
> すが。

今回の私の用途でいえば、failed がブロックに渡されて、ブロックの返り値
で処理が続行すると都合がいいですね。ただ、これで扱える話って一般的なの
かなぁ。
-- 
[田中 哲][たなか あきら][Tanaka Akira]
「ふえろ! わかめちゃん作戦です$(C⊇」(Little Worker, 桂遊生丸)