On Mar 4, 2006, at 11:25 PM, James Edward Gray II wrote:

> On Mar 4, 2006, at 7:34 PM, Jamey Cribbs wrote:
>
>> #select { |r| (r.speed and r.speed > 300) or (r.range and r.range  
>> < 900) or (r.service_date and r.service_date < Date.today) }
>
> select { |r| r.speed > 300 or r.range < 900 or r.service_date <  
> Date.today rescue false }
>
>> You should be able to just write:
>>
>> #select { |r| r.speed > 300 or r.range < 900 or r.service_date <  
>> Date.today }
>
> I'm great with that goal really, I just don't think changing Ruby  
> semantics is the way to get there.
>
>> Anyway, I hear ya, James. You want me to quit messin' around with  
>> NilClass.
>
> Here's my new idea.  What about solving this with default values  
> for columns?  If speed was defaulting to 0 instead of nil, we  
> wouldn't have a problem.  That seems to me to be what these  
> example's intend anyway.
>
> Am I crazy?
>
> James Edward Gray II
>
>

Maybe. NULL is not equal to zero in SQL DBs for similar reasons why 0  
and "" aren't false in ruby. (Consider if you want the product of all  
values in a given column, if NULLs are true NULLs this will cause no  
problems, if NULLs are zeros well then your product is all messed up)  
Of course if you know its ok for  your data to have 0 as a sane  
default that's another thing altogether. The other issue when you  
really really care about NULLs in my experience is doing outer joins.  
Which since KirbyBase doesn't really do joins (AFAIK) by itself,  
maybe it doesn't  matter in this case.