In article <E1Kj3Iz-0003yT-HU / x61.netlab.jp>,
  Yukihiro Matsumoto <matz / ruby-lang.org> writes:

> 上記の文は「上書きはふさわしい動作ではない(挙動が予想しがたい
> から)」という意見の表明でもあります。
>
> 上書きしてうれしいケースってありますか? あるいは上書きされな
> いとうれしくないケースは? そういうのがあれば、上書きを認める
> のにやぶさかでないです。

このあたりに関していろいろと考えているのですが、本質はモジュー
ル化の問題であろう、と思っています。

ある人があるコードを書くとき、そのコードは Unicode 専用と考
えて書くかもしれないし、EUC-JP 専用と考えて書くかもしれない
し、どんなエンコーディングにも対応できると考えて書くかもしれ
ません。

また、OS やネットワークの先などの外界も、それぞれ独自に文字
コードに関する仮定をもっています。

いずれにしてもそういうかたまりがモジュール (一般化して外界の
存在もモジュールとして考えましょう) としてあったとき、同じ種
類のモジュールを接続するのは問題ありません。また、どんなエン
コーディングにも対応できるモジュールは接続の自由度が高いとい
えるでしょう。さらには、どんなエンコーディングにも対応できる
というのもレベルがあって、ひとつのプロセスの中ではひとつとい
うこともあるでしょうし、ひとつのプロセスの中でも複数に対応で
きるということもあるでしょう。

さて、そのままでは接続できないモジュールが存在することはそう
いうものなので、そのときには文字コード変換が必要です。

ここで、モジュール間の相互作用すべてに変換コードを入れるとい
うのは、原理的には可能ですが、モジュール間で変換するというひ
とつの意図に対して、対応する作業が多いという問題があります。

おそらく、モジュール自身が、Unicode 専用なのか、EUC-JP 専用
なのか、あるいはどんなエンコーディングでも受け付けるか、とい
うことを宣言すると、ミスマッチが起こる界面で変換が行われると
いうのが妥当でしょう。(バイナリの問題を考えなければ、ですが)

私の見方では、Encoding.default_internal というのはここでいう
モジュールをプロセスで近似するものです。

また、[ruby-dev:36548] にある、
Encoding.with_internal(Encoding::UTF8) { ... }
は、ここでいうモジュールをダイナミックスコープで近似するもの
でしょう。

同様に (やはり [ruby-dev:36548] で触れられている) マジックコ
メントというのは、ファイル単位のレキシカルスコープと考えるこ
とが出来ます。

最初に述べたように、コードがどのような意図で実装されたかとい
うことを記述するには、記述と宣言が静的に対応するレキシカルス
コープが適切だと考えられます。

プロセスやダイナミックスコープをモジュールの単位として使うと、
コードの記述者の意図と宣言が食い違うことが起こります。これが
モジュール化の問題です。

Encoding.default_internal はプロセスでひとつという近似を行う
のでプロセス内のモジュールが複数のエンコーディングを使うと破
綻するわけです。

さて、破綻しない範囲で使うケースを考えます。そうすると、
Encoding.default_internal はプログラム自身の性質ですから、ソー
スコードに書いておきたいところです。
Encoding.default_external は外界の性質ですから、外界の状況に
応じて指定したいところです。
これらふたつは独立なので、-E が両方を指定するとしたら、上書
きではありませんが、片方ずつ指定したいということはあり得るで
しょう。それが [ruby-dev:36554] の指摘だと考えられます。
エラーになるのはどちらか一方が 2回以上 (あるいは 2種類以上)
指定された時と定義するのは素直な話だと思います。
-- 
[田中 哲][たなか あきら][Tanaka Akira]