[#34011] Should --verbose be equal to -v ? — Yugui <yugui@...>

Yuguiです。

15 messages 2008/03/10
[#34012] Re: Should --verbose be equal to -v ? — Yukihiro Matsumoto <matz@...> 2008/03/10

まつもと ゆきひろです

[#34105] rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...>

rational と complex が組み込みになったことで、lib/mathn.rb の意義は薄

29 messages 2008/03/22
[#34106] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/22

現時点で rational.rb と complex.rb を残しているのは、それが無難だから

[#34107] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/22

で、かなり選択肢を絞った叩き台です。

[#34120] Re: rational.rb, complex.rb and mathn.rb — keiju@... (石塚圭樹) 2008/03/24

けいじゅ@いしつかです.

[#34125] Re: rational.rb, complex.rb and mathn.rb — Shin-ichiro HARA <sinara@...> 2008/03/25

原です。

[#34130] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/25

> 私も Complex の組み込みは Rational とは比較にならないくらい、仕様が決め

[#34158] Complex組み込み — Masahiro TANAKA <masa16.tanaka@...>

Complexが組み込みになるそうですが、これはcomplex.rbを踏襲して、

49 messages 2008/03/27
[#34161] Re: Complex組み込み — Shin-ichiro HARA <sinara@...> 2008/03/28

原です。

[#34168] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/28

> 今までの Complex は、complex.rb にほぼ残して、たとえば Rational 成分

[#34186] Re: Complex組み込み — Shin-ichiro HARA <sinara@...> 2008/03/31

原です。

[#34187] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/31

> そうです。Complex が難しい、という話を書いておくと、

[#34193] Re: Complex組み込み — Yukihiro Matsumoto <matz@...> 2008/03/31

まつもと ゆきひろです

[#34203] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/04/01

> |僕としては、/ 演算子の振舞いについて前向きに検討してほしいです。

[#34215] Re: Complex組み込み — Yukihiro Matsumoto <matz@...> 2008/04/02

まつもと ゆきひろです

[#34166] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/28

> となるようですが、別の実装として、

[ruby-dev:34084] Re: 異なるエンコーディングだと同じバイト列でも==にならない件

From: "NARUSE, Yui" <yui.naruse@...>
Date: 2008-03-18 07:36:39 UTC
List: ruby-dev #34084
成瀬です。

2008/3/18  <rubikitch@ruby-lang.org>:
> > String#inspect は永続化用のメソッドではありませんから。
> > たぶん inspect で encoding が表示されてもうれしくないんじゃないですかねぇ。
>
> デバッグ時には助かるときもあると思いますが。
> たとえば、$VERBOSEや$DEBUGがtrueのときにエンコーディングも表示してくれるとか、
> そういう路線はありでしょうか?

状態を持つよりは常時の方がいいんじゃないですかね。

さておき、わたしはなんとなくごちゃごちゃしてしまうからいやじゃないかなぁと思っていたのですが、
デバッグ用だから必要十分な情報がほしいとか、
あと説得力を持って感じられたのは inspect を dump 目的で使う悪しき例が後を絶たないので、
あえて dump としては使えないようにしてしまえ、などといった指摘を IRC で受けて、
表示するのもいいのかもなぁと思い始めました。

まつもとさんも表示方法しだいでは受け入れてくれそうな雰囲気ですので[ruby-dev:34082]、
見やすい方法を提案するといいのではないでしょうか。

> > # 方向性としては、むしろ EUC-JP の "あ" と Shift_JIS の "あ" で == が成立するとか、
> > # そっちの方向に進むのがあるべき姿じゃないかと。
>
> なるほど。こっちの方が嬉しいです。
> それを推し進めるとして、「EUC-JP文字列 + Shift_JIS文字列」は現状でエラーですが、
> Shift_JIS文字列をEUC-JPに変換して結合するふうに挙動を変えたとしたら、
> どういう問題があるのでしょうか?
> やっぱりオーバーヘッドが大きすぎですか。

変換の際に用いるテーブルによって変換結果が変わったり、情報が落ちたりするので、
そういう暗黙の型変換には慎重になったほうがいいかなぁという気もします。
正直 EUC-JP と Shift_JIS だとおっかないんですが、
でも、UTF-8 + CP932 あたりだとありかなぁという気もする。。。
とすると、encoding によって区別するべきなのかなぁ・・・。

さておき US-ASCII が ascii compatible な encoding の string と 結合可能なのは、
まさにそういうことなんじゃないでしょうか。
変換がなく、問題のまず出ないであろうところを最初に実現したと。

> euc = "日本語"
> euc.encoding                    # => #<Encoding:EUC-JP>
> ascii = euc.dup.force_encoding "ASCII-8BIT"
> ascii.encoding                  # => #<Encoding:ASCII-8BIT>
> euc == ascii                    # => false
>
> 一方がASCII-8BITの場合に == をバイト列単位での比較に挙動を変更した場合、
> どういう問題があるのでしょうか?

文字列とバイト列の間で == が成り立つはずがないじゃないですか。

> それに伴い "文字列".as_binary とかでASCII-8BITなStringが作れると嬉しいです。

そこで欲しいものは本当に ASCII-8BIT な String なのでしょうか。
ケースバイケースではありますが、多分もっと別の何かなんじゃないですかね。

さておき、文法としてそれっぽいとは思います。
 euc.as_binary == ascii.as_binary

-- 
成瀬ゆい
naruse@airemix.com

In This Thread

Prev Next