[#29371] commit miss — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
7 messages
2006/09/01
[#29374] nil.to_s — Shugo Maeda <shugo@...>
前田です。
59 messages
2006/09/01
[#29375] Re: nil.to_s
— "U.Nakamura" <usa@...>
2006/09/01
こんにちは、なかむら(う)です。
[#29380] Re: nil.to_s
— Yukihiro Matsumoto <matz@...>
2006/09/01
まつもと ゆきひろです
[#29387] Re: nil.to_s
— Shugo Maeda <shugo@...>
2006/09/01
前田です。
[#29390] Re: nil.to_s
— Yukihiro Matsumoto <matz@...>
2006/09/01
まつもと ゆきひろです
[#29398] Re: nil.to_s
— "NARUSE, Yui" <naruse@...>
2006/09/01
成瀬です。
[#29400] Re: nil.to_s
— Yukihiro Matsumoto <matz@...>
2006/09/01
まつもと ゆきひろです
[#29405] Re: nil.to_s
— "NARUSE, Yui" <naruse@...>
2006/09/02
成瀬です。
[#29520] Re: nil.to_s
— Yukihiro Matsumoto <matz@...>
2006/09/07
まつもと ゆきひろです
[#29396] Re: nil.to_s
— "U.Nakamura" <usa@...>
2006/09/01
こんにちは、なかむら(う)です。
[#29409] Re: nil.to_s
— Yukihiro Matsumoto <matz@...>
2006/09/02
まつもと ゆきひろです
[#29376] Re: nil.to_s
— Shugo Maeda <shugo@...>
2006/09/01
前田です。
[#29406] too slow drb test — Tanaka Akira <akr@...>
とあるホスト (というのは td176.testdrive.hp.com ですが) で
5 messages
2006/09/02
[#29416] build failed on osx — Masatoshi SEKI <m_seki@...>
咳といいます。
8 messages
2006/09/02
[#29426] Re: build failed on osx
— Mitsuhiro Kondo <miche@...>
2006/09/03
近藤と申します。
[#29436] Re: build failed on osx
— Masatoshi SEKI <m_seki@...>
2006/09/03
咳といいます。
[#29423] Time#rfc2822 — Tadayoshi Funaba <tadf@...>
ふなばです。
9 messages
2006/09/03
[#29427] Re: Time#rfc2822
— Tanaka Akira <akr@...>
2006/09/03
In article <20060903.111434.71084310.tadf@dotrb.org>,
[#29429] Re: Time#rfc2822
— Tadayoshi Funaba <tadf@...>
2006/09/03
> Time が utc なら時差情報は出さないのが意図であると推測するの
[#29432] Re: Time#rfc2822
— Tanaka Akira <akr@...>
2006/09/03
In article <20060903.140151.74756121.tadf@dotrb.org>,
[#29447] Struct::Tms.instance_methods(false) contains false — Tanaka Akira <akr@...>
以下のように、instance_methods の結果に false が入ることがあります。
4 messages
2006/09/03
[#29473] ext/tk/tkutil — nobu@...
なかだです。
8 messages
2006/09/04
[#29474] Re: ext/tk/tkutil
— Yukihiro Matsumoto <matz@...>
2006/09/04
まつもと ゆきひろです
[#29491] symbol and string — Tanaka Akira <akr@...>
open-uri で :proxy=>nil という指定を行うと、以下のようにエラーになります。
33 messages
2006/09/05
[#29499] Re: symbol and string
— Yukihiro Matsumoto <matz@...>
2006/09/05
まつもと ゆきひろです
[#29500] Re: symbol and string
— Tanaka Akira <akr@...>
2006/09/05
In article <1157470154.047826.13379.nullmailer@x31.priv.netlab.jp>,
[#29503] Re: symbol and string
— Yukihiro Matsumoto <matz@...>
2006/09/06
まつもと ゆきひろです
[#29504] Re: symbol and string
— Tanaka Akira <akr@...>
2006/09/06
In article <1157505538.340126.8472.nullmailer@x31.priv.netlab.jp>,
[#29507] Re: symbol and string
— Yukihiro Matsumoto <matz@...>
2006/09/06
まつもと ゆきひろです
[#29512] Re: symbol and string
— keiju@... (石塚圭樹)
2006/09/06
けいじゅ@いしつかです.
[#29529] Re: symbol and string
— SASADA Koichi <ko1@...>
2006/09/08
ささだです。
[#29530] Re: symbol and string
— Yukihiro Matsumoto <matz@...>
2006/09/08
まつもと ゆきひろです
[#29532] Re: symbol and string
— Masatoshi SEKI <m_seki@...>
2006/09/08
咳といいます。
[#29533] Re: symbol and string
— Yukihiro Matsumoto <matz@...>
2006/09/08
まつもと ゆきひろです
[#29601] cgi.rbのformの挙動 — Fujioka <fuj@...>
藤岡です。
12 messages
2006/09/26
[#29602] Re: cgi.rbのformの挙動
— Yukihiro Matsumoto <matz@...>
2006/09/26
まつもと ゆきひろです
[#29603] Re: cgi.rbのformの挙動
— Fujioka <fuj@...>
2006/09/26
藤岡です。
[#29604] Re: cgi.rbのformの挙動
— "Nobuyoshi Nakada" <nobu@...>
2006/09/26
なかだです。
[ruby-dev:29386] String(nil)
From:
Shugo Maeda <shugo@...>
Date:
2006-09-01 14:15:01 UTC
List:
ruby-dev #29386
前田です。 まず、議論を簡単にするために、String(nil)の話とnil.to_sの話は分け て考えませんか? ここでは、String(nil)について考えたいと思います。 Yukihiro Matsumoto wrote: > |> というわけで、 > |> String(nil) #=> TypeError > |> Integer(nil) #=> TypeError > |> Float(nl) #=> TypeError > |> nil.to_s #=> "" > |> nil.to_i #=> 0 > |> nil.to_f #=> 0.0 > |> というあたりを希望します。 > | > |私もこれが一番一貫性があって、かつ便利だと思います。 > > うささんへのフォローでも書きましたが、少なくとも私には(より > 広い範囲で見た時に)一貫性があるようには見えません。 > Object#to_sがあるのにString(nil)が失敗する点とか。 「一貫性がある」という表現はよくなかったかもしれません。 「一貫性があるように見える」というところでしょうか。 言語を設計する側から見ると一貫性がないように見えるかもしれません が、その言語を使ってプログラムを読み書きする立場から見ると、わり と一貫性があるように見えるような気がします。 たぶん、to_iが変換が期待されるかどうか微妙な局面で、とりあえず便 利そうな値に変換してしまうのに対して、Integerがそういう局面ではエ ラーを出すので、Integer以外の他の型への変換でも同様の挙動を期待し てしまうのではないかと思います。 > 便利かどうかはまた別の話ですが。 > > ですから、どう一貫性があるのか、どう便利なのか、もうちょっと > 突っ込んで議論していきたいです。 便利なのは、使う時にどちらを選ぶかの基準がわかりやすいところだと 思います。なるべくエラーにせずに何らかの値に変換してほしい時は to_i系を使って、微妙な場合はエラーにしてほしい時はInteger()系を 使えばいいので。 -- 前田 修吾