From: Tom Sawyer <transami@...>
Date: 2002-07-08T01:35:57+09:00
Subject: Re: Pre-RCR... nil.empty?

> 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.

hmmm...that's a good case. by having empty? defined in nil, the only way
to scheck for an empty string and be sure its an empty string versus nil
is to use == ''. empty? wouldn't work anymore. of course you can still
ask using .nil? so i tend to think that's okay: usually nil is not
something being delt with directly, but is a side effect of, for
instance, a missing has parameter, etc.

~tranasmi

On Sun, 2002-07-07 at 07:41, David Alan Black wrote:
> Hi --
> 
> On Sun, 7 Jul 2002, Dave Thomas wrote:
> 
> > "Christoph" <chr_news@gmx.net> 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
> 
> 
-- 
~transami

"They that can give up essential liberty to obtain a little
 temporary safety deserve neither liberty nor safety."
	-- Benjamin Franklin