cpan

名器、じゃなくて名つっこみだ。

jankogaiの日記
はたしてchinで引っかかる事は問題ないのだろうか?

しかし、私がこれを直して$Encode::VERSION++するかというと、そうも行かないのがEncodeの難しいところである。

確かに、EncodeのBenevolent Dictatorは現在私である。Nick Ing-Simmonsから引き継いだ。しかし、私はことEncodeに関しては「大統領的」にではなく、「国連事務総長的」というか「総理大臣的」というか、とにかくなるべくDictatorshipを発揮しないよう心がけている。

というのも、Encoding aliasの名前やMappingといった問題というのは、CoderではなくUserに了解されるものなくてはならないからだ。特に自分のNative Languageでない言語に関する事は、必ずその言語のNativeに訪ねている。今回の場合はAudreyということになるだろう。もっともAudreyの場合は別のsensitiveな問題もあるのだけど、"::TW"と"::CN"まわりに関しては彼女が「担当」なのだから仕方がない。

実はEncodeのメンテナンスコストのほとんどは、Codingではなくこうしたやり取りに費やされている。'\x5C'をどうmappingするか(いわゆるbackslash/yen問題)一つとっても、そのために私が説得のために費やしたmailの数は2ダースはくだらない。

utf-8-strictとutf8の峻別問題に至っては、Larry本人の意思まで確認した。なにしろラクダ本の記述に結果として逆らうことになるからだ。

まあ今回の'chin'問題はせいぜいmail一往復で済むと思うのだが、いかにEncodeの仕様<変更>に関してPortersも私も慎重かは、Perl 5.8.8のReleaseの際にEncode 2.14が出ていたにも関わらず、Encode 2.12のまま済ましたということでも明らかだろう。

逆に新Encodingの追加、関数の別名定義など、今あるものの仕組みを変えないものであれば、かなりのdictatorshipを発揮できるしそうしてきた。

そういうわけで、Encodeはあまり「添削」の対象としてとりあげるのは微妙に思える。文字コードの政治性を過小評価してはならない。正直私もその開発にどっぷり使ってみるまでは、そのことを充分理解してなかったし、今も充分理解しているかは率直なところ不安だ。文字コードの世界というのは、ほんと誰もが文句があるけど、誰も責任を負いたがらないものなのだ。

添削が不要というわけではない。ただその添削には、大統領のスピーチ原稿を添削するような繊細が必要だということだ。文法的に正しく、より流暢であればいいというわけではない。'a'にするか'the'にするかで国際問題になりうる世界なのだ。

弾モノの添削であれば、むしろEncode-JIS2KUnicode-UnihanLingua-JA-Numbersあたりがおすすめか。これらであれば「国際問題化」が少ないので。

あと、結構お願いしたいのがPODの添削。もう少しきちんと整理したいのだけど。Codeの方はかなり安定しているので、これからはこちらが課題だと思う。

それにしても、これを書くにあたって改めて自分のCPAN directoryを眺めてみたが、地味系ばかりなのに我ながら苦笑してしまった。これからはもっと添削してもらえやすそうなModuleを書くようにしようかな....

Dan the Encode Maintainer