[#36672] [Bug #616] instance_eval and Module#to_s — Shyouhei Urabe <redmine@...>

Bug #616: instance_eval and Module#to_s

12 messages 2008/10/06

[#36750] [Bug #650] Marshal.load raises RegexpError — Shyouhei Urabe <redmine@...>

Bug #650: Marshal.load raises RegexpError

30 messages 2008/10/15
[#36769] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/17

まつもと ゆきひろです

[#36771] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/17

卜部です。

[#36772] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/17

まつもと ゆきひろです

[#36773] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/17

卜部です。

[#36784] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/18

まつもと ゆきひろです

[#36785] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/18

卜部です。

[#36793] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/19

まつもと ゆきひろです

[#36794] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/19

Yukihiro Matsumoto さんは書きました:

[#36823] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/21

まつもと ゆきひろです

[#36830] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/21

もとの正規表現にバグがあるのは認めますが、それに巻き込まれてでかいPStore

[#36833] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/21

まつもと ゆきひろです

[#36764] Re: [ruby-cvs:27036] Ruby:r19818 (trunk): * transcode.c (str_transcode0): String#encode without argument now — Martin Duerst <duerst@...>

まつもとさん、こんばんは。

11 messages 2008/10/17
[#36767] Re: [ruby-cvs:27036] Ruby:r19818 (trunk): * transcode.c (str_transcode0): String#encode without argument now — Yukihiro Matsumoto <matz@...> 2008/10/17

まつもと ゆきひろです

[#36799] Re: [ruby-cvs:27036] Ruby:r19818 (trunk): * transcode.c (str_transcode0): String#encode without argument now — Martin Duerst <duerst@...> 2008/10/20

まつもとさん、こんにちは。

[#36774] ConverterNotFoundError while making Ruby in Windows(trunk) — Masaki Suketa <masaki.suketa@...>

助田です。

13 messages 2008/10/17
[#36797] Re: ConverterNotFoundError while making Ruby in Windows(trunk) — "U.Nakamura" <usa@...> 2008/10/20

こんにちは、なかむら(う)です。

[#36800] Re: ConverterNotFoundError while making Ruby in Windows(trunk) — "U.Nakamura" <usa@...> 2008/10/20

こんにちは、なかむら(う)です。

[#36789] [Bug #660] 数字を3桁ずつコンマで区切るsprintf書式指定 — "rubikitch ." <redmine@...>

Bug #660: 数字を3桁ずつコンマで区切るsprintf書式指定

13 messages 2008/10/19

[#37007] [Bug:1.9] 1+1+1+...+1 dumps core — "Yusuke ENDOH" <mame@...>

遠藤です。

13 messages 2008/10/31

[ruby-dev:36838] Re: [ruby-cvs:27036] Ruby:r19818 (trunk): * transcode.c (str_transcode0): String#encode without argument now

From: Tanaka Akira <akr@...>
Date: 2008-10-21 08:31:52 UTC
List: ruby-dev #36838
In article <6.0.0.20.2.20081021131113.0ad9c398@localhost>,
  Martin Duerst <duerst@it.aoyama.ac.jp> writes:

> 勿論そうですよ。ユーザは encode をどの場面に使うのかは
> なかなか予想しにくいです。逆にファイル名であっても
> 表示のためだけや変換ガ可能を知っている上出の可能性も
> なきにもあらず。

たしかに、表示のためだけ、というケースでは replace が適切で
しょうね。

しかし、変換可能であることを知っているケースは、replace にす
る必要はないのではないでしょうか。むしろ、なにか問題があって
変換可能でなかったときにすぐ気がつけるように、例外のほうがい
いのではないでしょうか。

> そういう意見も確かにあります。でも現在には引数無しの encode で
> 無条件に replace されてしまいますよね。田中さんはそれでいいと
> 思いますか。

そのようにデザインされる理由は理解できます。

想定される用法がいくつかあれば、それらに応じた仕様が共存する
ようにデザインされるというのは Ruby では珍しい話ではありませ
ん。たとえそれらが相互に一貫しなくても、そのような非一貫性は、
意味のある非一貫性でしょう。

> 「不適切」は場合によります。「不適切」だと思われたら変更すべきです。
> こちらとして「拡張したがる」とかではなく、(Encoding の) 引数無しと
> 引数ありの方は :replace でしたら :replace で、そうではなかったら
> 例外で統一した方が筋が通って分かりやすいと思っています。

一般に、Ruby ではその類の一貫性は最優先の要素ではありません。

プログラマが情報を失わないように意図するというのは、ファイル
名を含めそれなりにありそうな話です。そのときには replace は
邪魔です。問題が起きたことに即座に気がつくことが難しくなりま
す。

たしかに存在する用法を、一貫性のために無視するというのは期待
されません。

> その上に、ファイル名の内部の対応を encode でやろうとしたら、
> ただ例外が出ればいいというわけではありませんよね。例外を
> rescue し、その時に ASCII-8BIT のままにしないといけませんよね。
> そういうことを考えたら、「どうせい気をつけないといけないので、
> 例外を出して欲しいということも簡単に書けるのではないか」
> という考え方もあります。ようするに、

長さについては、それぞれの用法がどの程度あるか、という点が問
題になります。

ここで短くしたいというケースは、どういうアプリケーションで発
生しますか?

default_internal を指定して、エンコーディングはあまり気にし
ないでやるときの用法を簡単にするというのが無引数 encode の意
図でしょう。

引数のある encode がデフォルトで replace になっていたほうが
いいというケースはどういうアプリケーションが想定されますか?

最初に表示という話がありましたが、他にありますか?

そういうアプリケーションは、情報を失わないようにしたいという
アプリケーションとはどちらが多いでしょうか?

どういう時に嬉しくて、どういう時に悲しいのか、ということを具
体的に考えるべきではないでしょうか。たとえば、表示だけなら、
encode ではなく tty へ出力する IO のときにするという案も考え
られるかもしれません。そのように、用法について具体的に考えれ
ば、人間の意図をより精度良く推測できる方法を考えられるかもし
れません。

> もしかしてもう一つ似た様な問題があります。
>  *     Encoding::Converter::XML_ATTR_CONTENT_DECORATOR
>  *     Encoding::Converter::XML_ATTR_QUOTE_DECORATOR
> の内一つは :xml => :attr に相当するが、どちかははっきりしないし、
> もう一つはどういう用途なのかもはっきりしません。

どちらも直接に対応するものではありません。

> にした方が、結果を "" 内でも '' 内でも使えるようになります。
> 「xml: :attr の結果は必ず "" 内」というのは制限として
> ちょっと狭いのではないかと思います。勿論 XML だけを考えると
> &apos; でも大丈夫ですが、HTML では正式にはだめで、IE6 で実際に
> だめのので、数字を使った方がいいと思います。

xml: :attr と指定した encode 自身が "..." と括りますので、'...'
の形式を気にする心配はありません。

xml: :attr を適用した結果を属性値全体として使用するのがお薦
めです。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

In This Thread