[ruby-dev:33127] Re: Binary String

永井＠知能．九工大です．

From: "NARUSE, Yui" <[e-mail]>
Subject: [ruby-dev:33123] Re: Binary String
Date: Tue, 15 Jan 2008 21:09:23 +0900
Message-ID: <[e-mail]>
> あぁ、tk_call_without_enc は変換しないんですね。それでは、バイナリデータ
> を要求するメソッドでは tk_call_without_enc を使えば意図しない変換は行わ
> れないんじゃないですか？

それを呼ぶ前段階で変換が必要ですから，解決しません．

例えば，複数の属性を設定 (属性名=>値の Hash で与える) するメソッドで，
テキストを与えねばならない属性と binary を与えねばならない属性とが
混じります (他にも，数値，ウィジェット等々が混じります)．

この Hash を tk_call に渡すべき引数列に展開するメソッドが
あるわけですが，そのメソッドは非常に広い範囲で使われています．
binary かどうかを指定できないなら，そのメソッドは使えなくなります．
呼ばれた後だとどれを binary として扱うべきか判断できません．
呼ばれる前に binary やその他を処理してしまうなら
引数列への展開処理はメソッドとして分けるようなものではなくなります．
で，それぞれに binary やその他の処理が必要なら，
非常に広い範囲でソースを書き換えて，
同じような記述を大量に行う必要が生じます．
これは到底受け入れられる話ではありません．

> > Ruby 1.9 で，magic comment がなければ ASCII-8BIT になり
> > binary == ASCII-8BIT とするのであるならば，
> > これまで動いていた Ruby 1.8 のスクリプトに対しては
> > 次のようになると思います．
> > 
> > (1) これまでと同様に動くようにするため，
> >     Ruby 1.8 と同様に binary を明示する情報を付与する．
> > 
> >     せっかく encoding 情報を持つようになったのに，
> >     それを利用しないという方法です．
> >     でも，一般ユーザは ASCII-8BIT を binary として
> >     使おうとするかもしれません．
> >     似て異なる情報を持たせねばならないという
> >     気持ちの悪い状況ではあります．
> 
> BINARY を定義したのにユーザーが　ASCII-8BIT をバイナリとして用いるケース
> を想定していらっしゃいますか？

あ，Tk で TK_BINARY のような encoding を定義するケースではなく，
Ruby 1.8 でやっているように無理やり @encoding というような
インスタンス変数で情報を付与するケースを考えてました．

> えーっと、まず、1.9 では Kernel#* がいくつか消えていたり、多重代入に変更
> が入ったり、、、string[i] が 文字を返すようになったりといった非互換な変
> 更が大量に入っているので、既存のスクリプトが修正なしに Ruby 1.9 で動くと
> いうことはある程度の規模ならばまずあり得ないと思います。よって、1.8 向け
> のコードがそのまま動くというのはもとより諦めていただかねばなりません。

どれもこれも動くというのは誰も期待していないと思います．
小振りのツール程度で，非互換部分を使っていないようなものも
世の中には多数存在しますよね．

> magic comment を定義しないことによる問題については定義してくださいの一言
> です。magic comment が未定義なことに由来する不都合はユーザー側の責任で
> しょう。どうも、magic comment の意義を過小評価していらっしゃるようです
> が、magic comment なしで自動推測によってかろうじて動いていたコードは、別
> の環境に持って行ったら化けるんですよ？そんなコードが許されるはずがない
> じゃないですか。

Ruby 1.9 で magic comment なしに「他所の」環境に持っていけば
動かない可能性が高いですよというのは当然ですし，
そういうケースまですべて自動推測で救済しようとは思っていません．
ローカルでこれまで利用できていたものが全滅してしまうのは避けたい，
少しでも多くそのまま使えるようにしてやりたいと考えているだけです．

> > というわけで，本当に最後の質問です．
> > binary encoding 導入，または ASCII-8BIT と UNKNOWN-8BIT の区別は
> > どうしてもダメですか？
> 
> え、これで最後なんですか？まだ、永井さんはどこに問題があるのかを把握して
> いらっしゃらないように思われます。問題を把握できていない方の修正案ではそ
> の問題が本当に解決できるのかわかりませんし、わたしは binary encoding 導
> 入では問題の解決はできないと考えています。

すみません．
議論 (になっていないのかもしれませんが) が完結していないのは
承知していますが，Ruby 1.8 との互換性維持のためというのが
一切受け入れられない (全滅もやむをえない) ということであれば，
これ以上はお願いしてもどうしようもないと思えるためです．

つまり，

 * binary に対しては ASCII-8BIT を与える．

 * ASCII-8BIT が来たときには binary であるとし，一切変換を行わない．

という対応で，互換性を捨てる (従来のスクリプトは極めて高い確率で
文字化けする) ということになります．

> 田中さんも仰られていますが、「具体的な問題の例」言い換えればテストケース
> があると理解しやすいように思います。ある種の極限状態——ユーザからもTcl/Tk
> 自体からもデータを受け取り、そのデータはバイナリデータのこともテキスト
> データのこともあるというメソッドが存在し、

冒頭で示したものは，そうしたメソッドとは言えませんか？

>                                          さらに受け取るテキストデータが
> ASCII-8BIT のままである正当な理由があるケース——がもし存在するならば

これについてはよくわかりません．
田中さんがおっしゃっている MIME のケースのように，
知らないものに対して dummy encoding を定義せずに 
ASCII-8BIT を使うというケースがどの程度想定されるべきかなど，
ASCII-8BIT となる or せざるをえないケースが
十分に理解できていないためです．
-- 
                                       永井 秀利 （九工大 知能情報）
                                           [e-mail]