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

everyone's probably already seen this, but just in case:

http://www.rubygarden.com/article.php?sid=241

in reference to Christoph: why the sarcasim? these methods have been
very useful for me, again and again. they make my code clearer and have
saved me time.

~transami


On Sun, 2002-07-07 at 03:19, Christoph wrote:
> 
> "David Alan Black"  in message
> ....
> > On Sun, 7 Jul 2002, Dave Thomas wrote:
> ....
> > > Would it be silly to have a predefined method:
> > >
> > >    def nil.empty?
> > >       true
> > >    end
> ....
> > Also it feels to me that the idea of a Boolean empty? test for nil
> > implies that there's the logical possibility of nil not being empty.
> > In other words, emptiness might be too rich a characteristic for nil
> > to have, or something like that.
> ....
> 
> 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)
> 
> fitting in well with  nil.to_i == 0 and the recent addition nil.to_f  ==
> 0.0.
> 
> My feeling that all of those extra nil functionalities waters down nil's
> ``nilness''.  In numerical terms the correct interpretation of nil is
> sometimes    +/- infinity (not to be mistaken with the  fake
> Float infinities)   or even -1.  For example, the silly expression
> 
>   b.max.to_i < a.max.to_i # => true for all Array's  b < a
> 
> as long as  b != [].   If the line
> 
>              stringy.nil? || stringy.empty?
> 
> becomes to repetitive one can always make an harmless
> alteration like
> 
> class NilClass
>     def noe?() true end
> end
> 
> class String
>     alias :noe? :empty?
> end
> 
> 
> /Christoph
> 
> 
> 
-- 
~transami

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