From: David Alan Black Date: 2002-07-07T22:41:55+09:00 Subject: Re: Pre-RCR... nil.empty? Hi -- On Sun, 7 Jul 2002, Dave Thomas wrote: > "Christoph" writes: > > > Yeah, I agree whole heartedly. Following Dave's logic it makes sense > > to define the all time favorites > > > > nil#each (do nothing - very useful for tree stuff) > > > > or even > > > > nil#collect (returning the empty Array) > > Of course, nil.to_a already returns [], so nil#each arguably _should_ > iterate zero times to be consistent with itself, and once you have an > #each, why not include Enumerable...? > > To my mind it isn't a question of what nil is as much as a question of > pragmatics. If I find myself performing the same double-barreled test > using nil and something else, I ask myself if maybe the behavior of > nil could be improved. But you could also argue that there's an element of chance or coincidence here. Going back to your original problem, it's true that cgi.params["param"][0] could be either nil or "", and that both of those are unacceptable. But nil and "" crop up, in this context, for different reasons: nil indicates no param named "param", while "" indicates an existent but zero-length value. Let's say that you wanted to check for nil (no such param), and also wanted to reject the string "abc". All other values (including empty string) are acceptable. Then you'd have: if string.nil? or string == "abc" ... which makes sense because the two tests clearly relate to different problems (missing param vs. unacceptable value). Now, you could argue that: if string.nil? or string == "" is just a special case of that. The fact that the string you don't want happens to be the same as nil.to_s is, arguably, just a coincidence. The two tests are still testing for very different things, not each testing for half of one thing. Still sort of devil's advocate, but I'm warming to my own argument :-) David -- David Alan Black home: dblack@candle.superlink.net work: blackdav@shu.edu Web: http://pirate.shu.edu/~blackdav