[ruby-dev:29405] Re: nil.to_s

成瀬です。

Yukihiro Matsumoto wrote:
> この人工的な例からnil.to_sが""であるべき理由を読み取ることは
> できませんでした。この例は「存在しないキーに対して空文字列が
> ほしい」ということなんだと思うんですが、そういう目的のために
> Hashにはデフォルト値が用意されてますよね。

きっちり書くならば、デフォルト値や fetch(key, "")、
hoge || "" 等を使うべきですね。

もうちょっと実際にありそうな例ですと、
<form action="nil.cgi">
<input name="name">
<input type="submit">
</form>
という HTML から、というCGIに投稿する場合でしょうか
CGIはデフォルト "" ですが、、webrick は nil なのでエラーが出ます。
require'webrick/cgi'
class MyCGI < WEBrick::CGI
  def do_GET(req,res)
    res.body = 'Hello, '+req.query['name']
  end
end
MyCGI.new.start

また、入力が空の時に、
res.body = 'input your name'
  if req.query['name'].nil? or req.query['name'].empty?
と書くのをおっくうがって、
  if req.query['name'].to_s.empty?
と書くのも結構あるかと。
# http://www.google.com/search?hl=ja&lr=&q=to_s.empty%3F
# 1000件引っかかりました
ruby 1.9 でも grep するとひっかかります。
ext/extmk.rb:    unless $destdir.to_s.empty? or $mflags.include?("DESTDIR")
ext/extmk.rb:unless $destdir.to_s.empty?
ext/tk/sample/tkextlib/treectrl/demo.rb:      unless sty.to_s.empty?
lib/soap/httpconfigloader.rb:    if value.nil? or value.to_s.empty?
lib/yaml/baseemitter.rb:                        return "" if
text.to_s.empty?
lib/yaml/rubytypes.rb:            unless val['mods'].to_s.empty?
lib/yaml/ypath.rb:            unless str.to_s.empty?

# 本当は nil.empty? があるといいんですけど。

> |to_s の場合は前田さんの [ruby-dev:29393] に同旨ですが、
> |なにかに nil の変換結果を加えても「なんでもない」のだから、
> 
> 「なにかに nil の変換結果を加えても「なんでもない」」かどう
> かは自明ではないと思います。つまり、「なぜそうあるべきか」と
> いうことが示せれば、nil.to_sが""であり、to_i, to_fなども残す
> という結論を導けるのでは。

「なぜそうあるべきか」ですか。
互換性を言っても面白くないので論理的に行ってみます。

思うに nil が入力として飛び込んで来る事態は基本的に異常事態であり、
このようなエラー状態をどう扱うか考えることになります。

このような場合一般に二つの手法、
* エラーが起きたらそこで止めて対処を迫る手法
* エラーが起きても適当に回避して先に進める手法
があるでしょう。
今回の場合、"nil" や 例外が前者にあたり、
自明ではありませんが "" や 0 が後者になる事は後で述べます。

# “Failure-Obliviousness in Google”「エラー忘却型コンピューティング」
# http://www.radiumsoftware.com/0608.html#060823


さて、to_s ですが、
得体の知れない入力を to_s.empty? してみるという方法を筆頭に、
とりあえず to_s してから考える方法がしばしば使われている点、
to_s は全ての Object が持つありふれたメソッドである点、
より strict であると期待される to_str が別に存在する点を考慮すると、
そこでエラーとみなして停止されるよりも、
先の“Failure-Obliviousness in Google”の言葉を借りると
「発生したエラーを「無かったこと」」にしたい場合であろうと推測します。

「エラーを無かった事にしたい」からは、
 「なにかに nil の変換結果を加えても「なんでもない」」ことは導けます。
よって、to_s について、string + nil.to_s == string が期待されます。
つまり、零元が期待され、文字列においては "" でしょう。

to_i は to_s ほどに一般的ではありませんが、
Ruby 1.9 の ruby/ 下において手元では 1068行で出現 (to_sは2011)
するほどにありふれており、
またより厳密なことが期待される to_int が別に存在します。
よって、これもまた、エラーを無かった事にしたいメソッドでしょう。
よって、整数ならば 0 でしょう。

to_f は to_float のようなメソッドもありませんし、
to_s や to_i 等に比べれば使用頻度も一桁落ちますが、
to_s, to_i, to_a と同じ to_一文字 系のメソッドであるため、
同様にカジュアル (言い換えればルーズ) なものと通常推測されるでしょう。
よって、小数では 0.0 が適当でしょう。

そういえば、to_a もありますが、これも同様に零元 [] が適当かと。

一方の String() 系はどうなんでしょうかね。
十分に一般的かつルーズであることが期待されるならば、
例外は出すべきではないでしょうし、
ある程度厳密であることが期待されるならば、
to_s 系でなく to_str / to_int / to_ary を利用するべきでしょう。

課題として出ていた puts と print の実装は、
 puts nil  #=> puts ""
 print nil #=> print ""
に変更するべきでしょう。
不用意に nil を puts に放り込むようなケースで、
nil かどうかを意識したいとは思わないと考えます。


まとめると、
* nil はエラーを示す値
* エラーで止めたいなら "nil" か例外
* エラーでも進みたければ零元
* to_s 系はエラーでも進みたい
* to_str 系は止めたいかな
* String() 系はどちらだろう # to_s 系か to_str 系かにあわせるべき

-- 
NARUSE, Yui  <[e-mail]>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA