From: Gavin Kistner <gavin@...>
Date: 2005-02-22T23:32:37+09:00
Subject: Re: Proposal for nil, 0, and "" in an if statement

On Feb 22, 2005, at 7:19 AM, Peter Hickman wrote:
>> I don't have actual code, but imagine looping through records 
>> returned with financial data, and you want to print out a "-" if the 
>> field is missing -or- zero. The whole "this field doesn't have any 
>> meaningful information that contributes to the sum of the column" 
>> spreadsheet thing.
>>
> Might this not cause trouble with databases. A database record 
> (returned
> as a structure or object) would have NULL == nil for fields with no
> value which is not the same as a field with a definite value such as 0.

Yes, there are many cases where you DO want to distinguish between nil 
and 0. These cases are already handled by the current behavior of Ruby.

It's just that there are also other cases where you want 0, nil, "", 
false, [], and {} to all behave the same way. (Perhaps not a single use 
case that encompasses all of those, but certainly cases like the above 
where you want to know "Is there a value in here that I care about, or 
not?" without having to test the klass or duck type it.)

Consider a method that returns either an array of matches, or nil, but 
sometimes returns an empty array. Wouldn't it be nicer to be able to do 
something like:

unless obj.foo.vapid?
	...
end

instead of something like:
val = obj.foo
if val && !val.empty?
	...
end

(and yes, you can probably golf with that to make it more terse)

The problem gets worse as you start dealing with arguments passed to 
your methods, and your desire to be really flexible about what types of 
values you accept.