ruby-dev

須藤です。

収束しない気もするのでとりあえずまとめておきます。
（誰か助けて）

  * エンコーディング検出機能の導入

    田中さん: 提案
    他の人（まつもとさん含む）: 賛成 or 反対しない

  * モジュール名

    田中さん: EncDet ->? EncDetect
              （よく使って欲しい機能だから短くしたい）
              エンコーディング関連の機能が別に増えるのなら
              Encoding::XXXでも可？
    須藤: Encoding::Detector
          * 省略されるとなんだかわからない
          * そんなに使う機会はないだろう
    他の人: いろいろ

    ファイル名などはモジュール名が決まれば付随して決まるはず

  * ファイルを開いて検出したエンコーディングを検出して設定す
    る機能（EncDetect.open）

    田中さん: 検出のためにはファイルopen時に処理を行う必要が
              あるのでopenしてエンコーディングを検出・設定す
              るAPIがいい

    須藤: openするところまで含むとファイル以外に使えないからIOに
          エンコーディングを検出・設定する
          API（io.detect_encoding!）を追加して、openとは独立
          に使えるAPIがいい。でも、使うときはreadする前とか
          に呼んでね、という注意が必要。


In <[email protected]>
  "[ruby-dev:33933] Re: encdet.rb" on Mon, 25 Feb 2008 17:01:13 +0900,
  Tanaka Akira <[email protected]> wrote:

> > でも、net/httpじゃなくてnethttpだったら戸惑わないとかいうもの
> > でもなくて、普段使わないライブラリだから戸惑ったというのもあ
> > るような気がします。
> 
> 最初だけではなく、require を書くたびに、なぜ必要性もないのに
> "/" が必要にしてあるのか憤りを感じたので、普段使わないから、
> というだけでは説明できません。

私は"/"が細分化とかグループ化とか具体化されている、というよ
うなイメージがあるので、net/httpはネットワーク関係のHTTPとい
う風に思い、憤りは感じませんでした。ディレクトリの区切りが
"/"なのに影響を受けているのかもしれません。

> > 私はXXXYYYだとXXXとYYYの切れめが分かりづらいのでそこで少し戸
> > 惑うことがあります。（特にWEBrickのやつ。）なので、私は密か
> > に"#{モジュール名.doncase}.rb"普及を拒みたいと思っています。
> 
> 最初に述べたように、"#{モジュール名.doncase}.rb" がなにを示
> しているのかよくわからないので、なんともいえません。

XxxYyyというモジュールはxxxyyy.rbというファイル名にするとい
う習慣のことを言いたかったのでした。

> 問題はそもそも分類すべきかどうかというところだと思います。

私は「エンコーディング関連の機能」の「検出機能」という風に考
えてしまうんでよね。たとえ、今は「エンコーディング関連の機能」
が一つしかなくても。

> > XMLファイルを開いてgsubするとか、grepしたいとかいう場合もあ
> > る気がします。
> 
> えーと、その適当さがいいのだ、という (以下略)

ひとつ具体例をあげると、SF.netにHTML（全部がXHTMLというわけで
はないですが）をアップロードする時にSF.netのロゴを入れるとき
に使うことがあります。（SF.netにアップロードするHTMLには
SF.netのロゴを入れなきゃいけないので。）

  html = html.gsub(/</body>/, "<img ...>\n</body>")

こういうときにはXMLパーサを使うのは面倒になります。

まぁ、どうでもいいですね。


> > chdirがよくわかないのですが、openしたあとでもFile#pathでどう
> > にかならないものでしょうか？
> 
> File#path が相対パスな場合、chdir されてしまうと、指している
> 場所が変わってしまいます。

chdirする前にfile.detect_encoding!（仮）してね、というのでは
弱いでしょうか？


> 私の経験からいうと、コマンドが出力に magic comment や BOM を
> つけるというのは少なくとも Unix ではあまりないのではないかと
> 思います。

たしかにそうですね。変なところで頑張ろうとしてしまいました。

StringIOやTempfileなどIOっぽいファイル以外のものにも使いたく
ない？と言いたかっただけでした。


> > であれば、やっぱりopenの第二引数で指定できるくらいの使いやす
> > さまで頑張って欲しいです。
> 
> 私はそうしたいとは思っていません。

やはり、EncDet.openがそれほどたくさん使われるものなのかがわか
りません。

今のところ、具体例としてRDocでのRubyスクリプトの読み込み、と
いうのがでていますが、それ以外の場合で使われることは多いので
しょうか？というのも、スクリプトを読み込むことはそんなにない
のではないかと思っているからです。PythonやEmacsで編集するファ
イルでmagic commentを使っているのはわかるのですが、それらの
ファイルを読み込むことが多いのかがわかりません。

また、CERN httpd形式はよく使われているのか、そしてそれを利用
したファイルを読み込むことは多いのかというのもわかりません。


そういう場面が多いのであれば名前を短くしたいという欲求はわか
らなくもないです。ただ、私の経験ではそんなにないんじゃないか
なぁという感じです。


> > コメントの書き方がフォーマットによって違うので難しい気がしま
> > す。
> 
> えぇ、ですから、生成するのは magic comment の部分だけで、コ
> メントは呼出側がどうにかすることになるでしょう。
> 
> 例えば、(名前はともかくとして)
> EncDet.make_magic_comment("euc-jp") が 
> "-*- coding: euc-jp -*-" を返すとか。

うーん、使いやすいでしょうか。
もし、今後XMLをサポートした場合は↑の形式は使えませんよね。
検出はmagic comment以外も頑張るけど、出力はmagic commentのみ
サポートというのでもいいでしょうけど、出力もライブラリがうま
い具合に頑張ってほしい気がします。（やるなら）