https://redmine.ruby-lang.org/
https://redmine.ruby-lang.org/favicon.ico?1711330511
2009-02-02T13:02:53Z
Ruby Issue Tracking System
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=2903
2009-02-02T13:02:53Z
ko1 (Koichi Sasada)
<ul><li><strong>Assignee</strong> set to <i>matz (Yukihiro Matsumoto)</i></li><li><strong>Priority</strong> changed from <i>3</i> to <i>Normal</i></li><li><strong>Target version</strong> set to <i>1.9.2</i></li></ul><p>=begin</p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=2907
2009-02-02T13:08:13Z
matz (Yukihiro Matsumoto)
matz@ruby.or.jp
<ul></ul><p>=begin<br>
まつもと ゆきひろです</p>
<p>In message "Re: <a href="/issues/973">[ruby-dev:37679]</a> [FEATURE:trunk] EncDet again"<br>
on Sat, 3 Jan 2009 19:21:37 +0900, "Yugui (Yuki Sonoda)" <a href="mailto:yugui@yugui.jp" class="email">yugui@yugui.jp</a> writes:</p>
<p>|私はIOへの機能追加が良いのではないかと思いました。<br>
| io/encdet.rb</p>
<p>encはencodingの省略として(私には)認知できますが、detをdetect<br>
の省略形として認識するのにはやや困難です。ただ、どうしてもダ<br>
メというほどではないです。</p>
<p>| IO::magic_open(*args) -> 内部でIO::openを呼び出し</p>
<p>反対。magicでもmagicalでも名前が「魔法」すぎてなにをするのか<br>
まったくわかりません。</p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=2933
2009-02-03T04:08:33Z
naruse (Yui NARUSE)
naruse@airemix.jp
<ul></ul><p>=begin<br>
成瀬です。</p>
<p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>まつもと ゆきひろです</p>
<p>In message "Re: <a href="/issues/973">[ruby-dev:37679]</a> [FEATURE:trunk] EncDet again"<br>
on Sat, 3 Jan 2009 19:21:37 +0900, "Yugui (Yuki Sonoda)" <a href="mailto:yugui@yugui.jp" class="email">yugui@yugui.jp</a> writes:</p>
<p>|私はIOへの機能追加が良いのではないかと思いました。<br>
| io/encdet.rb</p>
<p>encはencodingの省略として(私には)認知できますが、detをdetect<br>
の省略形として認識するのにはやや困難です。ただ、どうしてもダ<br>
メというほどではないです。</p>
</blockquote>
<p>いっそ prelude に入れてしまいませんか。<br>
そうすればライブラリ名に関しては悩む必要がなくなります。</p>
<blockquote>
<p>| IO::magic_open(*args) -> 内部でIO::openを呼び出し</p>
<p>反対。magicでもmagicalでも名前が「魔法」すぎてなにをするのか<br>
まったくわかりません。</p>
</blockquote>
<p>素直に IO::detect_open あたりは。</p>
<p>--<br>
NARUSE, Yui <a href="mailto:naruse@airemix.jp" class="email">naruse@airemix.jp</a></p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=2934
2009-02-03T08:51:26Z
ko1 (Koichi Sasada)
<ul></ul><p>=begin<br>
ささだです.</p>
<p>NARUSE, Yui wrote::</p>
<blockquote>
<p>いっそ prelude に入れてしまいませんか。<br>
そうすればライブラリ名に関しては悩む必要がなくなります。</p>
</blockquote>
<p> そんなに使うものなんですか?</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=6968
2009-11-26T00:19:42Z
znz (Kazuhiro NISHIYAMA)
<ul></ul><p>=begin<br>
Pythonだとchardetという名前のライブラリがあるようなので、<br>
encdetでも良さそうな気がしますが、どうでしょうか?</p>
<p><a href="http://chardet.feedparser.org/" class="external">http://chardet.feedparser.org/</a><br>
=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=6970
2009-11-26T00:30:22Z
kou (Kouhei Sutou)
kou@cozmixng.org
<ul></ul><p>=begin<br>
須藤です。</p>
<p>In <a href="mailto:4b0d4b0e62b03_8c37c0cb6c133a@redmine.ruby-lang.org" class="email">4b0d4b0e62b03_8c37c0cb6c133a@redmine.ruby-lang.org</a><br>
"<a href="https://blade.ruby-lang.org/ruby-dev/39775">[ruby-dev:39775]</a> [Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: EncDet again (Rejected)" href="https://redmine.ruby-lang.org/issues/973">#973</a>] EncDet again" on Thu, 26 Nov 2009 00:19:42 +0900,<br>
Kazuhiro NISHIYAMA <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Pythonだとchardetという名前のライブラリがあるようなので、<br>
encdetでも良さそうな気がしますが、どうでしょうか?</p>
<p><a href="http://chardet.feedparser.org/" class="external">http://chardet.feedparser.org/</a></p>
</blockquote>
<p>わざわざわかりにくい名前を真似する必要はないと思います。<br>
(<em>私には</em>わかりにくいです。)</p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=6972
2009-11-26T00:59:48Z
naruse (Yui NARUSE)
naruse@airemix.jp
<ul></ul><p>=begin<br>
chardetはアウトだと思います、"det"じゃなくて"char"の方が。<br>
detの方も諸手を挙げて賛成というわけではありません。</p>
<p>しかし、現状rdoc絡みやerb周りなど、EncDetを再発明しようとした挙句に失敗してしまった例が散見されており、<br>
そろそろこのライブラリは標準添付しないと悪しき遺産を残しかねないと憂慮しています。</p>
<p>言い換えると、このライブラリの用途は様々な場面で必要である一方、実装が意外と難しいので、<br>
適切なライブラリを標準添付で提供しなければならないと思っています。<br>
たとえ名前で合意がつかなかったとしても、yuguiさん判断で名前を決定し、添付するべきであろうと。</p>
<p>で、わたしは encdet でもいいと思っています。<br>
なぜなら、これは使われるライブラリであり、使ってればどうせ慣れるから。<br>
=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=6974
2009-11-26T02:05:15Z
knu (Akinori MUSHA)
knu@ruby-lang.org
<ul></ul><p>=begin<br>
ライブラリ名は encoding でいいんじゃないですか?</p>
<p>将来ほかにもEncoding絡みの追加ライブラリの必要が出てきたら、<br>
encoding/detect などに移して encoding はよく使いそうな encoding/* をすべて require<br>
(あるいはautoload)するようにすれば互換性を保てます。</p>
<p>またクラス名も、実装は Encoding::Detector などわかりやすい名前の下で行いつつ、<br>
APIは(少なくともアプリケーションは)Encoding以外のクラス名を使わなくて済むように<br>
工夫すればいいと思います。<br>
=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=6975
2009-11-26T02:27:31Z
naruse (Yui NARUSE)
naruse@airemix.jp
<ul></ul><p>=begin</p>
<blockquote>
<p>ライブラリ名は encoding でいいんじゃないですか?</p>
</blockquote>
<p>encoding.rb はちょっと時期尚早じゃないかなぁ。</p>
<blockquote>
<p>またクラス名も、実装は Encoding::Detector などわかりやすい名前の下で行いつつ、</p>
</blockquote>
<p>その手の Java 的な「わかりやすい名前」が、必ずしも Ruby において「いい名前」ではない、<br>
ってのはこの話の論点の一つですよね。</p>
<blockquote>
<p>APIは(少なくともアプリケーションは)Encoding以外のクラス名を使わなくて済むように<br>
工夫すればいいと思います。</p>
</blockquote>
<p>その工夫が思いつかなくてたな晒しになっている現状、有効な案だとは思えません。</p>
<p>なお、open 等に detect をつっこめるほど EncDet について知見が集まっているとも考えがたいです。<br>
=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=6976
2009-11-26T02:50:05Z
kou (Kouhei Sutou)
kou@cozmixng.org
<ul></ul><p>=begin<br>
須藤です。</p>
<p>In <a href="mailto:4b0d6903e2a11_8c37d9e412135f0@redmine.ruby-lang.org" class="email">4b0d6903e2a11_8c37d9e412135f0@redmine.ruby-lang.org</a><br>
"<a href="https://blade.ruby-lang.org/ruby-dev/39781">[ruby-dev:39781]</a> [Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: EncDet again (Rejected)" href="https://redmine.ruby-lang.org/issues/973">#973</a>] EncDet again" on Thu, 26 Nov 2009 02:27:32 +0900,<br>
Yui NARUSE <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a> wrote:</p>
<blockquote>
<blockquote>
<p>またクラス名も、実装は Encoding::Detector などわかりやすい名前の下で行いつつ、</p>
</blockquote>
<p>その手の Java 的な「わかりやすい名前」が、必ずしも Ruby において「いい名前」ではない、<br>
ってのはこの話の論点の一つですよね。</p>
</blockquote>
<p><a href="http://doc.okkez.net/static/192/library/_builtin.html" class="external">http://doc.okkez.net/static/192/library/_builtin.html</a><br>
にあるクラス名・モジュール名をざっくり見てみると、クラス名・<br>
モジュール名を省略していない方が多いように見えます。</p>
<p>わかりやすいというのは省略しないということと解釈したのですが、<br>
わかりやすいというのとJava的というのは関係ない気がします。</p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=6978
2009-11-26T03:38:47Z
knu (Akinori MUSHA)
knu@ruby-lang.org
<ul></ul><p>=begin</p>
<blockquote>
<blockquote>
<p>ライブラリ名は encoding でいいんじゃないですか?</p>
</blockquote>
<p>encoding.rb はちょっと時期尚早じゃないかなぁ。</p>
</blockquote>
<p>その理由について何らかの材料をいただけないでしょうか。<br>
私の主張はライブラリ名として今使っても問題ないだろうという点なので。</p>
<blockquote>
<blockquote>
<p>またクラス名も、実装は Encoding::Detector などわかりやすい名前の下で行いつつ、</p>
</blockquote>
<p>その手の Java 的な「わかりやすい名前」が、必ずしも Ruby において「いい名前」ではない、<br>
ってのはこの話の論点の一つですよね。</p>
</blockquote>
<p>エンドユーザが使わない部分の名前として挙げたので、そこはどうでもいいと思います。</p>
<blockquote>
<blockquote>
<p>APIは(少なくともアプリケーションは)Encoding以外のクラス名を使わなくて済むように<br>
工夫すればいいと思います。</p>
</blockquote>
<p>その工夫が思いつかなくてたな晒しになっている現状、有効な案だとは思えません。</p>
</blockquote>
<p>まずはライブラリ名や実装クラス名の問題を取り除いて、エンドユーザが使うAPIに<br>
フォーカスすればこのissueはシンプルになるのではないでしょうか。</p>
<blockquote>
<p>なお、open 等に detect をつっこめるほど EncDet について知見が集まっているとも考えがたいです。</p>
</blockquote>
<p>ご自分が挙げられた IO::detect_open に即座の反対は寄せられていないし、<br>
十分いい名前だと思いますよ。何をdetectするのかという問いは、Encoding自体を<br>
必ずしも文字コードだけに収まらない概念とすれば答えになるでしょう。<br>
(そこの方針を私は把握していないのですが)</p>
<p><a href="https://blade.ruby-lang.org/ruby-dev/33628">[ruby-dev:33628]</a>から早20ヶ月。1.9にはちゃんと番人が居てくれるのだし、<br>
trunkに入れてみて、使ってみては直しを繰り返してこそ問題も見えて来るはず。</p>
<p>私などは新しく書くコードにもNKFを使う有様ですし、Nokogiriなどを見ても、<br>
みんな同じなんだなあと思います。最終版でなくていいから、「いずれこんな感じで<br>
できるようになるよ」というのを見せてほしいとみんな思っていますよ。<br>
=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=6979
2009-11-26T03:46:08Z
naruse (Yui NARUSE)
naruse@airemix.jp
<ul></ul><p>=begin<br>
成瀬です。</p>
<p>Kouhei Sutou wrote:</p>
<blockquote>
<blockquote>
<blockquote>
<p>またクラス名も、実装は Encoding::Detector などわかりやすい名前の下で行いつつ、<br>
その手の Java 的な「わかりやすい名前」が、必ずしも Ruby において「いい名前」ではない、<br>
ってのはこの話の論点の一つですよね。</p>
</blockquote>
</blockquote>
<p><a href="http://doc.okkez.net/static/192/library/_builtin.html" class="external">http://doc.okkez.net/static/192/library/_builtin.html</a><br>
にあるクラス名・モジュール名をざっくり見てみると、クラス名・<br>
モジュール名を省略していない方が多いように見えます。</p>
</blockquote>
<p>そこにある数々のクラス・モジュールのうち、<br>
自分でその名前を書く物って一部ではないでしょうか。<br>
例えば、BasicObject, Encoding::Converter, File::Constants などが<br>
念頭にあるのだと思いますが、どれも通常書く事はないはずです。</p>
<p>また、略されているのは<br>
ARGF, Bignum, Dir, ENV, Fixnum, GC, Hash, Proc, Regexp<br>
あたりですが、どれも超有名クラスですよね。</p>
<blockquote>
<p>わかりやすいというのは省略しないということと解釈したのですが、<br>
わかりやすいというのとJava的というのは関係ない気がします。</p>
</blockquote>
<p>Java では「わかりやすい名前」(=省略しない名前)を、<br>
「いい名前」であるとしているというイメージがあるので。</p>
<p>Ruby において省略しない事が必ずしもいい事ではなく、<br>
むしろあまり使うべきでないものに対して使われる事が多いのは<br>
前提に置くべきじゃないですかね。</p>
<p>--<br>
NARUSE, Yui <a href="mailto:naruse@airemix.jp" class="email">naruse@airemix.jp</a></p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=6980
2009-11-26T04:02:35Z
naruse (Yui NARUSE)
naruse@airemix.jp
<ul></ul><p>=begin<br>
成瀬です。</p>
<p>Akinori MUSHA wrote:</p>
<blockquote>
<blockquote>
<blockquote>
<p>ライブラリ名は encoding でいいんじゃないですか?<br>
encoding.rb はちょっと時期尚早じゃないかなぁ。</p>
</blockquote>
</blockquote>
<p>その理由について何らかの材料をいただけないでしょうか。<br>
私の主張はライブラリ名として今使っても問題ないだろうという点なので。</p>
</blockquote>
<p>まず前提として、Ruby のエンコーディングの命名は、<br>
IANA Charset の実際上の運用とは異なっています。<br>
つまり、世間では Shift_JIS という名前を Windows-31J として使っているのに対し、<br>
Ruby はその区別を厳格にする事を求め、ルーズにしていると Windows 環境では<br>
例外が上がるように設計されています。</p>
<p>Encoding や、magic comment を読む EncDet はこの枠内で動いています。<br>
ので、ここまでは Encoding に統合可能ではあるのですが、<br>
Encoding をあまり肥大化させると、それ以外の実際上の IANA Charset 的な、<br>
Ruby としては間違った世界のものも扱う必要が出てくるように思います。<br>
その場合の判断は後述の理由から、現時点では避けたいと考えています。</p>
<p>つまり、Encoding の本質について今は判断を避けたいのです。</p>
<blockquote>
<blockquote>
<blockquote>
<p>APIは(少なくともアプリケーションは)Encoding以外のクラス名を使わなくて済むように<br>
工夫すればいいと思います。<br>
その工夫が思いつかなくてたな晒しになっている現状、有効な案だとは思えません。</p>
</blockquote>
</blockquote>
<p>まずはライブラリ名や実装クラス名の問題を取り除いて、エンドユーザが使うAPIに<br>
フォーカスすればこのissueはシンプルになるのではないでしょうか。</p>
</blockquote>
<p>これは賛成です。</p>
<blockquote>
<blockquote>
<p>なお、open 等に detect をつっこめるほど EncDet について知見が集まっているとも考えがたいです。</p>
</blockquote>
<p>ご自分が挙げられた IO::detect_open に即座の反対は寄せられていないし、<br>
十分いい名前だと思いますよ。何をdetectするのかという問いは、Encoding自体を<br>
必ずしも文字コードだけに収まらない概念とすれば答えになるでしょう。<br>
(そこの方針を私は把握していないのですが)</p>
</blockquote>
<p>Encoding は文字コードのみを扱うべきだと、わたしは現時点で思っています。</p>
<blockquote>
<p>私などは新しく書くコードにもNKFを使う有様ですし、Nokogiriなどを見ても、<br>
みんな同じなんだなあと思います。最終版でなくていいから、「いずれこんな感じで<br>
できるようになるよ」というのを見せてほしいとみんな思っていますよ。</p>
</blockquote>
<p>Nokogiri は前述の IANA Charset ベースの話なので、EncDet より話は悲惨です。<br>
つまり、charset=Shift_JIS まわりで地雷を踏むことでしょう。</p>
<p>こっちがまともになるのはもうしばらくかかると思われます。<br>
この辺について、IANA 側で動く気配があるので、そちらの動きが見えるまでは<br>
Ruby 側で対処するつもりはありません。</p>
<p>--<br>
NARUSE, Yui <a href="mailto:naruse@airemix.jp" class="email">naruse@airemix.jp</a></p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=7024
2009-11-27T22:44:42Z
kou (Kouhei Sutou)
kou@cozmixng.org
<ul></ul><p>=begin<br>
須藤です。</p>
<a name="なんか本質的な話じゃない流れな気がしますが"></a>
<h1 >なんか、本質的な話じゃない流れな気がしますが。。。<a href="#なんか本質的な話じゃない流れな気がしますが" class="wiki-anchor">¶</a></h1>
<p>In <a href="mailto:4B0D7B56.9000002@airemix.jp" class="email">4B0D7B56.9000002@airemix.jp</a><br>
"<a href="https://blade.ruby-lang.org/ruby-dev/39784">[ruby-dev:39784]</a> Re: [Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: EncDet again (Rejected)" href="https://redmine.ruby-lang.org/issues/973">#973</a>] EncDet again" on Thu, 26 Nov 2009 03:45:54 +0900,<br>
"NARUSE, Yui" <a href="mailto:naruse@airemix.jp" class="email">naruse@airemix.jp</a> wrote:</p>
<blockquote>
<blockquote>
<p><a href="http://doc.okkez.net/static/192/library/_builtin.html" class="external">http://doc.okkez.net/static/192/library/_builtin.html</a><br>
にあるクラス名・モジュール名をざっくり見てみると、クラス名・<br>
モジュール名を省略していない方が多いように見えます。</p>
</blockquote>
<p>そこにある数々のクラス・モジュールのうち、<br>
自分でその名前を書く物って一部ではないでしょうか。<br>
例えば、BasicObject, Encoding::Converter, File::Constants などが<br>
念頭にあるのだと思いますが、どれも通常書く事はないはずです。</p>
<p>また、略されているのは<br>
ARGF, Bignum, Dir, ENV, Fixnum, GC, Hash, Proc, Regexp<br>
あたりですが、どれも超有名クラスですよね。</p>
</blockquote>
<p>Bignum, Fixnum, GC(!), Hash, (Proc,) Regexpは通常書くことは<br>
ないと思います。というのはよいとして、略されているものでも、<br>
そういう風に略されることが多いものな気がします。(ARGFは違い<br>
ますが。)</p>
<p>通常書くことがあり、略されていない超有名クラスもFile,<br>
Thread(?), Time(?), LoadErrorなどがあったりします。</p>
<p>略すにしてもそれがなんなのかが想像できるものがよいなぁと思い<br>
ます。私にはDetは難しいです。</p>
<blockquote>
<p>Ruby において省略しない事が必ずしもいい事ではなく、<br>
むしろあまり使うべきでないものに対して使われる事が多いのは<br>
前提に置くべきじゃないですかね。</p>
</blockquote>
<p>そういうわけじゃないと思っていました。<br>
まずは、省略せずにしておいて、よく使うから短くしたいなぁ、じゃ<br>
あ、短くするか、という流れかと思っていました。</p>
<p>エンコーディング検出処理は、どのくらいよく使われる処理。。。<br>
なんですかねぇ。どうなのかしら。</p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=7027
2009-11-28T00:35:16Z
naruse (Yui NARUSE)
naruse@airemix.jp
<ul></ul><p>=begin<br>
Kouhei Sutou wrote:</p>
<blockquote>
<p>略すにしてもそれがなんなのかが想像できるものがよいなぁと思い<br>
ます。私にはDetは難しいです。</p>
</blockquote>
<p>初期の名称案に EncDetect はありますね。<br>
これでもダメですか。</p>
<blockquote>
<p>エンコーディング検出処理は、どのくらいよく使われる処理。。。<br>
なんですかねぇ。どうなのかしら。</p>
</blockquote>
<p><a href="/issues/973">[ruby-dev:37679]</a> にて、標準ライブラリ内だけで三例報告されています。</p>
<blockquote>
<p>さて、現在私が知る限りRDocとERBとIRBがそれぞれ独自にマジックコメントを解<br>
釈してファイルを開く機能を実装しています。この重複具合は何らかの共通化の<br>
必要性を示しているのではないかと思います。</p>
</blockquote>
<p>--<br>
NARUSE, Yui <a href="mailto:naruse@airemix.jp" class="email">naruse@airemix.jp</a></p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=7044
2009-11-28T22:26:36Z
kou (Kouhei Sutou)
kou@cozmixng.org
<ul></ul><p>=begin<br>
In <a href="mailto:4B0FF194.2030809@airemix.jp" class="email">4B0FF194.2030809@airemix.jp</a><br>
"<a href="https://blade.ruby-lang.org/ruby-dev/39804">[ruby-dev:39804]</a> Re: [Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: EncDet again (Rejected)" href="https://redmine.ruby-lang.org/issues/973">#973</a>] EncDet again" on Sat, 28 Nov 2009 00:34:59 +0900,<br>
"NARUSE, Yui" <a href="mailto:naruse@airemix.jp" class="email">naruse@airemix.jp</a> wrote:</p>
<blockquote>
<p>Kouhei Sutou wrote:</p>
<blockquote>
<p>略すにしてもそれがなんなのかが想像できるものがよいなぁと思い<br>
ます。私にはDetは難しいです。</p>
</blockquote>
<p>初期の名称案に EncDetect はありますね。<br>
これでもダメですか。</p>
<blockquote>
<p>エンコーディング検出処理は、どのくらいよく使われる処理。。。<br>
なんですかねぇ。どうなのかしら。</p>
</blockquote>
<p><a href="/issues/973">[ruby-dev:37679]</a> にて、標準ライブラリ内だけで三例報告されています。</p>
<blockquote>
<p>さて、現在私が知る限りRDocとERBとIRBがそれぞれ独自にマジックコメントを解<br>
釈してファイルを開く機能を実装しています。この重複具合は何らかの共通化の<br>
必要性を示しているのではないかと思います。</p>
</blockquote>
</blockquote>
<p>私にとって3例は多くないので、Encと略すほどではないと感じます。</p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=7165
2009-12-04T21:16:55Z
yugui (Yuki Sonoda)
yugui@yugui.jp
<ul></ul><p>=begin<br>
2009/11/28 Kouhei Sutou <a href="mailto:kou@cozmixng.org" class="email">kou@cozmixng.org</a>:</p>
<blockquote>
<p>私にとって3例は多くないので、Encと略すほどではないと感じます。</p>
</blockquote>
<p>Encodingクラスがあるのに、EncXXXを定義するのはとても嫌です。<br>
成瀬さんの懸念も分かりますので encoding.rbは避けるとしても、やはりEncoding::XXXであって欲しいです。</p>
<p>ところで、先日IRCで挙がった話題ですが、EncDetは何を提供するのでしょうか。<br>
当初提案されたEncDetの機能はマジックコメントとBOMの解釈でした。このうち、BOMは既にFile.openに実装されています。<br>
ですから、今想定されるのはファイルの最初の一行からマジックコメントっぽいバイト列を探してそれに基づいて開く機能のみです。<br>
この機能が複数箇所で実装されているのでこれは、何らかの良いデフォルト実装を提供しなければならないというのが私の主張でした。<br>
この機能だけであるとすると、実は当面File.openの機能拡張のみで済んでしまうのではないでしょうか。たとえば、</p>
<p>File.open(path, "r:magic-comment")<br>
ないし<br>
File.open(path, "r:auto")<br>
のようにして。</p>
<p>--<br>
Yuki Sonoda (Yugui)<br>
<a href="mailto:yugui@yugui.jp" class="email">yugui@yugui.jp</a><br>
<a href="http://yugui.jp" class="external">http://yugui.jp</a></p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=9050
2010-03-17T22:46:40Z
mame (Yusuke Endoh)
mame@ruby-lang.org
<ul></ul><p>=begin<br>
遠藤です。</p>
<p>EncDet の件、どうしますか?<br>
Yugui さんが以下のような提案もしています。</p>
<blockquote>
<p>実は当面File.openの機能拡張のみで済んでしまうのではないでしょうか。たとえば、</p>
<p>File.open(path, "r:magic-comment")<br>
ないし<br>
File.open(path, "r:auto")<br>
のようにして。</p>
</blockquote>
<p>さて、</p>
<ol>
<li>EncDet 方式で決定する (名前はまつもとさんの好みで決める)</li>
<li>File.open 方式で決定する</li>
<li>1.9.2 を見送ってじっくり議論する</li>
</ol>
<p>のどれにしましょうか。</p>
<p>2 回も名前の議論で発散したようなので、議論を再開するより、まつもと<br>
さんの好みで決めてしまうのがよいのではないかと思います。</p>
<p>3 月末までに決定できないと自動的に #3 になります。</p>
<p>#2 の選択肢は実現可能性が検証されていない気がするので、「パッチを<br>
書いてみたら実は難しいことがわかった → 1.9.2 見送り」という危険が<br>
あるかもしれません。</p>
<p>--<br>
Yusuke ENDOH <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a><br>
=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=9061
2010-03-18T07:06:17Z
nobu (Nobuyoshi Nakada)
nobu@ruby-lang.org
<ul></ul><p>=begin<br>
なかだです。</p>
<p>At Wed, 17 Mar 2010 22:46:43 +0900,<br>
Yusuke Endoh wrote in <a href="https://blade.ruby-lang.org/ruby-dev/40687">[ruby-dev:40687]</a>:</p>
<blockquote>
<ol start="2">
<li>File.open 方式で決定する</li>
</ol>
</blockquote>
<blockquote>
<p>#2 の選択肢は実現可能性が検証されていない気がするので、「パッチを<br>
書いてみたら実は難しいことがわかった → 1.9.2 見送り」という危険が<br>
あるかもしれません。</p>
</blockquote>
<p>別に難しくはありません。</p>
<p>$ ./ruby -Eus-ascii -e 'ARGV.each{|file|open(file, "r:magic-comment"){|f|p [f.path, f.external_encoding]}}' version.h lib/rexml/rexml.rb lib/rubygems/package.rb<br>
["version.h", #<a href="Encoding:US-ASCII" class="external">Encoding:US-ASCII</a>]<br>
["lib/rexml/rexml.rb", #<a href="Encoding:UTF-8" class="external">Encoding:UTF-8</a>]<br>
["lib/rubygems/package.rb", #<a href="Encoding:ISO-8859-1" class="external">Encoding:ISO-8859-1</a>]</p>
<p><br>
diff --git c/include/ruby/io.h i/include/ruby/io.h<br>
index e05a0f5..f067831 100644<br>
--- c/include/ruby/io.h<br>
+++ i/include/ruby/io.h<br>
@@ -96,4 +96,5 @@ typedef struct rb_io_t {<br>
/* #define FMODE_PREP 0x00010000 */<br>
#define FMODE_SETENC_BY_BOM 0x00100000<br>
+#define FMODE_SETENC_BY_MAGIC_COMMENT 0x00200000</p>
<p>#define GetOpenFile(obj,fp) rb_io_check_closed((fp) = RFILE(rb_io_taint_check(obj))->fptr)<br>
diff --git c/io.c i/io.c<br>
index 60afd6c..60761f0 100644<br>
--- c/io.c<br>
+++ i/io.c<br>
@@ -4125,4 +4125,6 @@ rb_io_ext_int_to_encs(rb_encoding *ext, rb_encoding *intern, rb_encoding **enc,<br>
}</p>
<p>+#define is_magic_comment(str) (STRCASECMP(str, "magic-comment") == 0)<br>
+<br>
static void<br>
parse_mode_enc(const char *estr, rb_encoding **enc_p, rb_encoding **enc2_p)<br>
@@ -4166,5 +4168,5 @@ parse_mode_enc(const char *estr, rb_encoding **enc_p, rb_encoding **enc2_p)<br>
ext_enc = rb_enc_from_index(idx);<br>
else {</p>
<ul>
<li>if (idx != -2)</li>
</ul>
<ul>
<li>if (idx != -2 && !is_magic_comment(estr))<br>
rb_warn("Unsupported encoding %s ignored", estr);<br>
ext_enc = NULL;<br>
@@ -4337,6 +4339,11 @@ rb_io_extract_modeenc(VALUE *vmode_p, VALUE *vperm_p, VALUE opthash,<br>
has_enc = 1;<br>
parse_mode_enc(p+1, &enc, &enc2);</li>
</ul>
<ul>
<li>
<pre><code> if (io_encname_bom_p(p+1, 0))
</code></pre>
</li>
</ul>
<ul>
<li>
<pre><code> if (io_encname_bom_p(p+1, 0)) {
fmode |= FMODE_SETENC_BY_BOM;
</code></pre>
</li>
<li>
<pre><code> p += 4;
</code></pre>
</li>
<li>
<pre><code> }
</code></pre>
</li>
<li>
<pre><code> if (is_magic_comment(p+1)) {
</code></pre>
</li>
<li>
<pre><code> fmode |= FMODE_SETENC_BY_BOM | FMODE_SETENC_BY_MAGIC_COMMENT;
</code></pre>
</li>
<li>
<pre><code> }
}
</code></pre>
else {<br>
@@ -4605,10 +4612,44 @@ io_strip_bom(VALUE io)<br>
}</li>
</ul>
<p>-static void<br>
-io_set_encoding_by_bom(VALUE io)<br>
+int rb_magic_comment_encoding(const char *str, long len);<br>
+<br>
+static int<br>
+io_parse_encoding_comment(VALUE io)<br>
{</p>
<ul>
<li>int idx = io_strip_bom(io);</li>
</ul>
<ul>
<li>VALUE line = rb_io_gets(io);</li>
<li>char *s;</li>
<li>long n;</li>
<li>if (NIL_P(line)) return 0;</li>
<li>s = RSTRING_PTR(line);</li>
<li>n = RSTRING_LEN(line);</li>
<li>if (n >= 2 && s[0] == '#' && s[1] == '!') {</li>
<li>VALUE shbang = line;</li>
<li>line = rb_io_gets(io);</li>
<li>if (NIL_P(line)) {</li>
<li>
<pre><code> rb_io_ungetbyte(io, shbang);
</code></pre>
</li>
<li>
<pre><code> return 0;
</code></pre>
</li>
<li>}</li>
<li>rb_io_ungetbyte(io, line);</li>
<li>s = RSTRING_PTR(line);</li>
<li>n = RSTRING_LEN(line);</li>
<li>line = shbang;</li>
<li>}</li>
<li>rb_io_ungetbyte(io, line);</li>
<li>while (n > 0 && (*s == ' ' || *s == '\t')) {</li>
<li>s++;</li>
<li>n--;</li>
<li>}</li>
<li>if (n <= 0 || *s != '#') return 0;</li>
<li>return rb_magic_comment_encoding(s, n);<br>
+}</li>
</ul>
<ul>
<li>if (idx) {<br>
+static void<br>
+io_guess_encoding(VALUE io, int fmode)<br>
+{</li>
</ul>
<ul>
<li>int idx;</li>
<li>if (((fmode & FMODE_SETENC_BY_BOM) &&</li>
<li>(idx = io_strip_bom(io)) != 0) ||</li>
<li>((fmode & FMODE_SETENC_BY_MAGIC_COMMENT) &&</li>
<li>(idx = io_parse_encoding_comment(io)) != 0)) {<br>
rb_io_t *fptr;<br>
GetOpenFile(io, fptr);<br>
@@ -4638,5 +4679,5 @@ rb_file_open_generic(VALUE io, VALUE filename, int oflags, int fmode, convconfig<br>
fptr->fd = rb_sysopen(fptr->pathv, oflags, perm);<br>
io_check_tty(fptr);</li>
</ul>
<ul>
<li>if (fmode & FMODE_SETENC_BY_BOM) io_set_encoding_by_bom(io);</li>
</ul>
<ul>
<li>
<p>io_guess_encoding(io, fmode);</p>
<p>return io;<br>
@@ -6396,5 +6437,5 @@ rb_io_initialize(int argc, VALUE *argv, VALUE io)<br>
fp->stdio_file = stderr;</p>
</li>
</ul>
<ul>
<li>if (fmode & FMODE_SETENC_BY_BOM) io_set_encoding_by_bom(io);</li>
</ul>
<ul>
<li>io_guess_encoding(io, fmode);<br>
return io;<br>
}<br>
diff --git c/parse.y i/parse.y<br>
index 340a825..a42c8f6 100644<br>
--- c/parse.y<br>
+++ i/parse.y<br>
@@ -6248,13 +6248,15 @@ magic_comment_marker(const char *str, long len)<br>
}</li>
</ul>
<p>+typedef int rb_magic_comment_func(const char *name, long nlen, const char *value, long vlen, void *arg);<br>
+<br>
static int<br>
-parser_magic_comment(struct parser_params *parser, const char *str, long len)<br>
+parse_magic_comment(const char *str, long len, rb_magic_comment_func *func, void *arg)<br>
{</p>
<ul>
<li>VALUE name = 0, val = 0;</li>
</ul>
<ul>
<li>VALUE name = 0;<br>
const char *beg, *end, *vbeg, *vend;<br>
#define str_copy(_s, _p, _n) ((_s) <br>
? (rb_str_resize((_s), (_n)), <br>
MEMCPY(RSTRING_PTR(_s), (_p), char, (_n)), (_s)) \</li>
</ul>
<ul>
<li>: ((_s) = STR_NEW((_p), (_n))))</li>
</ul>
<ul>
<li>
<p>: ((_s) = rb_str_new((_p), (_n))))</p>
<p>if (len <= 7) return FALSE;<br>
@@ -6266,7 +6268,4 @@ parser_magic_comment(struct parser_params <em>parser, const char <em>str, long len)<br>
/</em> %r"([^\\s\'\":;]+)\s</em>:\s*("(?:\\.|[^\"])<em>"|[^\"\\s;]+)[\s;]</em>" */<br>
while (len > 0) {<br>
-#ifndef RIPPER</p>
</li>
</ul>
<ul>
<li>const struct magic_comment *p = magic_comments;<br>
-#endif<br>
char *s;<br>
int i;<br>
@@ -6321,24 +6320,68 @@ parser_magic_comment(struct parser_params *parser, const char *str, long len)<br>
if (s[i] == '-') s[i] = '_';<br>
}</li>
</ul>
<ul>
<li>if ((*func)(s, n, vbeg, vend - vbeg, arg)) break;</li>
<li>}</li>
<li>
<li>return TRUE;<br>
+}</li>
<li>
</ul>
<p>+static int<br>
+magic_comment_i(const char *name, long nlen, const char *value, long vlen, void *arg)<br>
+{</p>
<ul>
<li>struct parser_params *parser = arg;<br>
#ifndef RIPPER</li>
</ul>
<ul>
<li>do {</li>
<li>
<pre><code> if (STRNCASECMP(p->name, s, n) == 0) {
</code></pre>
</li>
<li>
<pre><code> n = vend - vbeg;
</code></pre>
</li>
<li>
<pre><code> if (p->length) {
</code></pre>
</li>
<li>
<pre><code> n = (*p->length)(parser, vbeg, n);
</code></pre>
</li>
<li>
<pre><code> }
</code></pre>
</li>
<li>
<pre><code> str_copy(val, vbeg, n);
</code></pre>
</li>
<li>
<pre><code> (*p->func)(parser, s, RSTRING_PTR(val));
</code></pre>
</li>
<li>
<pre><code> break;
</code></pre>
</li>
</ul>
<ul>
<li>const struct magic_comment *p = magic_comments;</li>
<li>do {</li>
<li>if (STRNCASECMP(p->name, name, nlen) == 0) {</li>
<li>
<pre><code> char *val;
</code></pre>
</li>
<li>
<pre><code> if (p->length) {
</code></pre>
</li>
<li>
<pre><code> vlen = (*p->length)(parser, value, vlen);
}
</code></pre>
</li>
</ul>
<ul>
<li>} while (++p < magic_comments + numberof(magic_comments));</li>
</ul>
<ul>
<li>
<pre><code> val = ALLOCA_N(char, vlen + 1);
</code></pre>
</li>
<li>
<pre><code> memcpy(val, value, vlen);
</code></pre>
</li>
<li>
<pre><code> val[vlen] = '\0';
</code></pre>
</li>
<li>
<pre><code> (*p->func)(parser, name, val);
</code></pre>
</li>
<li>
<pre><code> break;
</code></pre>
</li>
<li>}</li>
<li>} while (++p < magic_comments + numberof(magic_comments));<br>
#else</li>
</ul>
<ul>
<li>dispatch2(magic_comment, name, val);</li>
</ul>
<ul>
<li>dispatch2(magic_comment, name, val);<br>
#endif</li>
</ul>
<ul>
<li>}</li>
</ul>
<ul>
<li>return FALSE;<br>
+}</li>
<li>
</ul>
<p>+static int<br>
+parser_magic_comment(struct parser_params *parser, const char *str, long len)<br>
+{</p>
<ul>
<li>return parse_magic_comment(str, len, magic_comment_i, (void *)parser);<br>
+}</li>
<li>
</ul>
<p>+static int<br>
+find_magic_comment_encoding(const char *name, long nlen, const char *value, long vlen, void *arg)<br>
+{</p>
<ul>
<li>char *val;</li>
<li>switch (nlen) {</li>
<li>
<pre><code> case 8:
</code></pre>
</li>
<li>if (STRNCASECMP("en", name, 2) != 0) return FALSE;</li>
<li>name += 2;</li>
<li>
<pre><code> case 6:
</code></pre>
</li>
<li>if (STRNCASECMP("coding", name, 6) != 0) return FALSE;</li>
<li>}</li>
<li>vlen = parser_encode_length(0, value, vlen);</li>
<li>memcpy(val = ALLOCA_N(char, vlen + 1), value, vlen);</li>
<li>val[vlen] = '\0';</li>
<li>*(int *)arg = rb_enc_find_index(val);<br>
return TRUE;<br>
}</li>
</ul>
<p>+int<br>
+rb_magic_comment_encoding(const char *str, long len)<br>
+{</p>
<ul>
<li>int idx = 0;</li>
<li>if (!parse_magic_comment(str, len, find_magic_comment_encoding, &idx)) return 0;</li>
<li>return idx;<br>
+}</li>
<li>
</ul>
<p>static void<br>
set_file_encoding(struct parser_params *parser, const char *str, const char *send)<br>
</p>
<p>--<br>
--- 僕の前にBugはない。<br>
--- 僕の後ろにBugはできる。<br>
中田 伸悦</p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=9131
2010-03-20T00:55:13Z
mame (Yusuke Endoh)
mame@ruby-lang.org
<ul></ul><p>=begin<br>
遠藤です。</p>
<p>2010年3月18日7:05 Nobuyoshi Nakada <a href="mailto:nobu@ruby-lang.org" class="email">nobu@ruby-lang.org</a>:</p>
<blockquote>
<p>At Wed, 17 Mar 2010 22:46:43 +0900,<br>
Yusuke Endoh wrote in <a href="https://blade.ruby-lang.org/ruby-dev/40687">[ruby-dev:40687]</a>:</p>
<blockquote>
<p>? 2) File.open 方式で決定する</p>
</blockquote>
<blockquote>
<p>#2 の選択肢は実現可能性が検証されていない気がするので、「パッチを<br>
書いてみたら実は難しいことがわかった → 1.9.2 見送り」という危険が<br>
あるかもしれません。</p>
</blockquote>
<p>別に難しくはありません。</p>
</blockquote>
<p>なるほど。もうパッチがあるということなら #2 でもいいかもですね。</p>
<p>正直に言うと、本気で実現可能性を疑っていたわけではなく、選択肢を<br>
増やしても決定の可能性が下がるだけじゃないかと思ってのことでした。</p>
<p>再度いいますが、3 月末までに合意できないと自動的に流れますので、<br>
導入を狙っている人たちはがんばってください。</p>
<p>--<br>
Yusuke ENDOH <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=9158
2010-03-20T16:01:00Z
yugui (Yuki Sonoda)
yugui@yugui.jp
<ul></ul><p>=begin<br>
2010/3/20 Yusuke ENDOH <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a>:</p>
<blockquote>
<p>再度いいますが、3 月末までに合意できないと自動的に流れますので、<br>
導入を狙っている人たちはがんばってください。</p>
</blockquote>
<p>議論の過程でもうちょっと実例が集まることを期待したんですが、結局3例のままですよね。<br>
ならば流してもうちょっと慎重に検討しても良いのではないでしょうか。まずはredmineにfeatureとして登録されたことで将来的に検討される可能性が残ったということで私は満足です。</p>
<p>--<br>
Yuki Sonoda (Yugui)<br>
<a href="mailto:yugui@yugui.jp" class="email">yugui@yugui.jp</a><br>
<a href="http://yugui.jp" class="external">http://yugui.jp</a></p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=9199
2010-03-22T12:11:19Z
mame (Yusuke Endoh)
mame@ruby-lang.org
<ul><li><strong>Target version</strong> changed from <i>1.9.2</i> to <i>2.0.0</i></li></ul><p>=begin<br>
遠藤です。</p>
<p>2010年3月20日16:00 Yugui <a href="mailto:yugui@yugui.jp" class="email">yugui@yugui.jp</a>:</p>
<blockquote>
<p>2010/3/20 Yusuke ENDOH <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a>:</p>
<blockquote>
<p>再度いいますが、3 月末までに合意できないと自動的に流れますので、<br>
導入を狙っている人たちはがんばってください。</p>
</blockquote>
<p>議論の過程でもうちょっと実例が集まることを期待したんですが、結局3例のままですよね。<br>
ならば流してもうちょっと慎重に検討しても良いのではないでしょうか。まずはredmineにfeatureとして登録されたことで将来的に検討される可能性が残ったということで私は満足です。</p>
</blockquote>
<p>ということなので、target を 1.9.x にさせていただきます。</p>
<p>個人的には標準ライブラリ中に 3 例 (RDoc, ERB, IRB) もあれば十分な気が<br>
しますし、<a href="https://blade.ruby-lang.org/ruby-dev/39779">[ruby-dev:39779]</a> の成瀬さんによると、</p>
<blockquote>
<p>しかし、現状rdoc絡みやerb周りなど、EncDetを再発明しようとした挙句に失敗してしまった例が散見されており、<br>
そろそろこのライブラリは標準添付しないと悪しき遺産を残しかねないと憂慮しています。</p>
<p>言い換えると、このライブラリの用途は様々な場面で必要である一方、実装が意外と難しいので、<br>
適切なライブラリを標準添付で提供しなければならないと思っています。<br>
たとえ名前で合意がつかなかったとしても、yuguiさん判断で名前を決定し、添付するべきであろうと。</p>
</blockquote>
<p>とのことなので、入れた方がいいんじゃないかなと思っていました。</p>
<p>--<br>
Yusuke ENDOH <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a><br>
=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=9206
2010-03-22T19:34:26Z
yugui (Yuki Sonoda)
yugui@yugui.jp
<ul></ul><p>=begin<br>
2010/3/22 Yusuke Endoh <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>:</p>
<blockquote>
<blockquote>
<p>言い換えると、このライブラリの用途は様々な場面で必要である一方、実装が意外と難しいので、<br>
適切なライブラリを標準添付で提供しなければならないと思っています。<br>
たとえ名前で合意がつかなかったとしても、yuguiさん判断で名前を決定し、添付するべきであろうと。</p>
</blockquote>
<p>とのことなので、入れた方がいいんじゃないかなと思っていました。</p>
</blockquote>
<p>本当にこの(2)のインターフェースで良いのかもう少し事例がないと自信を持てないんですね。<br>
悪しき実装がはびこるのも頭が痛いですが、まだ3例以外にはびこってる例が見あたらないので待っても良いのではないでしょうか。</p>
<p>--<br>
Yuki Sonoda (Yugui)<br>
<a href="mailto:yugui@yugui.jp" class="email">yugui@yugui.jp</a><br>
<a href="http://yugui.jp" class="external">http://yugui.jp</a></p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=13390
2010-09-14T16:45:18Z
shyouhei (Shyouhei Urabe)
shyouhei@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li></ul><p>=begin</p>
<p>=end</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=23609
2012-02-08T05:51:22Z
kosaki (Motohiro KOSAKI)
kosaki.motohiro@gmail.com
<ul></ul><blockquote>
<blockquote>
<p>実は当面File.openの機能拡張のみで済んでしまうのではないでしょうか。たとえば、</p>
<p>File.open(path, "r:magic-comment")<br>
ないし<br>
File.open(path, "r:auto")<br>
のようにして。</p>
</blockquote>
</blockquote>
<p>すでにパッチが投稿されているようですが、これでダメな理由がよく分かりません。実装があるものに対してrejectはないかなと思っているのでまつもとさんがコメントしないと永久に棚晒しじゃないですかねえ</p>
Ruby master - Feature #973: EncDet again
https://redmine.ruby-lang.org/issues/973?journal_id=23764
2012-02-13T21:26:00Z
mame (Yusuke Endoh)
mame@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Rejected</i></li></ul><p>遠藤です。</p>
<blockquote>
<p>実装があるものに対してrejectはないかなと思っているので<br>
まつもとさんがコメントしないと永久に棚晒しじゃないですかねえ</p>
</blockquote>
<p>実装がある feature チケットでも、</p>
<p>たなざらしにする<br>
-> feature チケットがたまる<br>
-> より一層 feature チケットをみなくなる<br>
(まつもとさんだけでなく誰も)</p>
<p>という悪循環になるだけだと思うので、進展の気配が感じられない<br>
ものは一旦 reject します。</p>
<p>ついでにコメント。</p>
<blockquote>
<p>現状rdoc絡みやerb周りなど、EncDetを再発明しようとした挙句に失敗してしまった例が散見されており、<br>
そろそろこのライブラリは標準添付しないと悪しき遺産を残しかねないと憂慮しています。</p>
</blockquote>
<p>というのが 2 年前の話なので、まずは現状どうなってしまったか<br>
(悪しき遺産は残りまくっているか) を調べてみるのはどうでしょう。</p>
<p>また、API や名前の議論ばかりされていますが、ユースケースとして<br>
挙がっている RDoc 、ERB 、IRB で本当に使えるのか、という議論<br>
がされていなかったように思います。<br>
当時どうなっていたかは見てませんが、現状を見てみました。</p>
<ul>
<li>
<p>RDoc<br>
magic comment をただ取り除くコードはあるけれど、encoding 名を<br>
抽出して何かに使う箇所は見つからない。</p>
</li>
<li>
<p>ERB<br>
magic comment から encoding 名をパースしているが、それは生成<br>
されるコードに magic comment を付けるためだけに使われ、文字列<br>
自体は ASCII-8BIT として処理されている。</p>
</li>
<li>
<p>IRB<br>
magic comment から encoding 名をパースして、その元 IO に set_<br>
encoding している。</p>
</li>
</ul>
<p>ということで、現状提案されていた API がそのまま通用しそうなのは<br>
IRB だけな気がします。</p>
<a name="主に-grep-で適当に調べただけなので間違ってたらすみません"></a>
<h1 >主に grep で適当に調べただけなので間違ってたらすみません<a href="#主に-grep-で適当に調べただけなので間違ってたらすみません" class="wiki-anchor">¶</a></h1>
<p>ただし、この実装が RDoc や ERB のバグだとしたら (encoding 名を<br>
ちゃんと使わないといけないのに使ってない、など) 、逆にやはり<br>
必要ということになるかもしれません。</p>
<p>reopen する際は、この辺を調査して議論の材料とするといいかもしれ<br>
ません。</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p>