From: Hidetoshi NAGAI Date: 2010-05-12T10:57:31+09:00 Subject: [ruby-dev:41293] Re: [BUG:1.9] BINARY should not be ASCII-compatible 永井＠知能．九工大です． From: Yugui Subject: [ruby-dev:41290] Re: [BUG:1.9] BINARY should not be ASCII-compatible Date: Wed, 12 May 2010 08:42:14 +0900 Message-ID: > > ゴールを確認しましょう。どうせM17Nの問題が魔法のように解決するのはありえませ > > ん。Yuguiさんとしてはどうなるのが目標ですか? > (snip) > > * wycatsが黙る > > * 低レベルライブラリ作者が黙る > > * ユーザーが黙る > > 誰かが黙る必要もないと思うわけですよ。これまで-talkに流れているように常に、バグを書いてRubyがバグを検出したことについて文句を言う人がいるでしょうから。 > 一方、低水準ライブラリのバグを高水準の開発者が、事前検出できない程度に低くアプリケーションライフサイクルの中で遭遇する程度には高い確率で踏まされるのは悲劇です。 > 悲劇を言語が食い止められるならそうあるべきです。 ２年前（と言われて，あぁそんなに前になるのかと思いました (^_^)）の議題の際， それなりに頑張ってお願いしたつもりですが， 受け入れてもらえずにあきらめて工夫して対処したという経緯はあります． まぁ，「低レベル」ではないかもしれませんが， ライブラリ作者が「黙った」例ですよね． > アプリケーション開発者の悲劇を防ぎたいです。たとえば、ASCII-8BIT(1.8との互換性のためのもの, index > 0)とBINARY(octetのためもの)を分離して、 > ASCII-8BITは任意のエンコーディングと結合可能で結果はASCII-8BIT、という仕組みなんかはどうでしょうか。 こういう仕組みも含めて却下されたのが２年前の議論だと認識しています． よってライブラリ作者側としては， 「現状が仕様である」として対処しているわけです． これを変更するのであれば，再び苦労を強いられます． しかも，互換性維持のために，単純に導入される以上の労力が 求められることになろうかと思います． # つまり，ライブラリ作者側が黙らねばなりません． この段階で仕様変更しようとするなら，1.9.2 リリースは全くの白紙に戻して すべての添付ライブラリについての対応チェックが必要となるはずです． 少なくとも Ruby/Tk としては，こんな時期に仕様変更されても 対応することはできないと考えています． そうまでしても仕様変更しなければならないものなのかを， ２年前の経緯も含めて十分に検討する必要があるはずです． 2.0 に向けての議論であれば反対するつもりはありませんが， 1.9.2 での導入の必要性があると考えて議論するのであれば， 1.9.2 リリース計画を白紙に戻すことを求めます． 期限を限られて済し崩し的に決められてしまうのは納得できません． 1.9.3 での導入を想定しての議論というのもあるでしょうけれど， そうなると現在の仕様に対応するライブラリ等も増えると考えられ， 悲劇の範囲も拡大するように思います． それゆえ，1.9.x での仕様変更議論は消極的ながら反対します． # 何というか，「何で今さら…」という感じがしています． -- 永井 秀利 (nagai@ai.kyutech.ac.jp) 九州工業大学 大学院情報工学研究院 知能情報工学研究系 知能情報メディア部門