From: Rick DeNatale <rick.denatale@...>
Date: 2007-10-16T06:39:00+09:00
Subject: Re: nil.to_i returning zero

On 10/15/07, mortee <mortee.lists@kavemalna.hu> wrote:
> Gerardo Santana Gómez Garrido wrote:
> > Chand Perrin wrote:
> >> What would you expect it to return, and why would you think that should
> >> be the expected behavior?
> >
> > I'd expect the same behavior as FalseClass and TrueClass: undefined method.
> >
> > Because if I want 0 would expect or send 0, not nil.to_i.
> > Because it doesn't make sense to me that nil, which means false also,
> > can be represented as zero, when zero doesn't mean false, but true.
>
> Hmmm. Why would you convert a variable/parameter to int if you want to
> use it in a boolean context, in the first place?...
>
> Do you think that to_i is expected to keep the boolean meaning of
> anything it's sent to, or throw an exception? I don't see why this would
> ever be related to each other (to_i and boolean operations).
>
> > mortee wrote:
> >> Well, if you'd like it so much, why not just redefine it in your own
> >> programs? Everyone else seems to expect it to return 0 instead of being
> >> hostile by throwing an exception...

In fact, I'm almost ready to go out on the limb and suggest that it
might be nice if:

class NilClass

   def +(aNumber)
       aNumber
   end

   def -(aNumber)
      0 - aNumber
   end

   alias_method :*, :to_i
   alias_method: :/, :to_i
end

which would allow sequences like:

  a ||= 0
  a += 1

To be just
  a += 1


As I said ALMOST ready to go out on a limb, since I haven't spent much
time pondering the consequences.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/