From: Phrogz <phrogz@...>
Date: 2007-10-16T05:05:03+09:00
Subject: Re: nil.to_i returning zero

On Oct 15, 1:02 pm, "Gerardo Santana Gómez Garrido"
<gerardo.sant...@gmail.com> wrote:
> John Joyce wrote:
> > If it returned nil, then you'd get exceptions and it would be
> > pointless to have nil respond to to_i
>
> You got it wrong. I'm not asking for #to_i returning nil.
> NilClass#to_i shouldn't be there in the first place.
>
> Jeremy McAnally wrote:
> > I expect to get a converted object or some *Error (TypeError maybe?)
> > back from any to_* method.  Giving me the same object back or nil
> > doesn't make any sense...
>
> You got it wrong too (am I that confusing? :).

I suspect the confusion comes from the fact that your initial post was
titled "nil.to_i returning zero". Apparently the subject was a red
herring. We might have gotten more swiftly to discussing the merits of
your beliefs/suggestions had the subject been titled (for example)
"nil.to_i (and nil.to_s) should not exist".

This isn't criticism - I know well how it sometimes occurs that only
after a discussion has taken place do I realize what question or
statement I was really trying to make. The discussion is part of the
clarifying process.

So, having refocused the discussion on the question: "Should NilClass
have a #to_i method?", let me throw in my opinion:

Various objects have methods that return an instance of a different
class. The most obvious is the #to_s method. By extension, your
argument that nil.to_i should not return 0 because 0 is a truth value
would further imply that false.to_s should not return "false" because
all strings are also truth values. Is it acceptable for an object (of
any class) to have a method that returns an object that behaves
differently under core language concepts (like boolean evaluation)? I
would say "yes".

So, what other reasons exist for wanting to do away with nil.to_i? The
main (only other?) argument seems to be, "nil is special, and I want
to know for sure when I get a nil value. It's so special, I should get
a NoMethodError if I try to do (just about) anything to it."

I agree that it's special. I've certainly seen that foo.id => 4 (when
foo is unexpectedly nil) can cause confusion.

However, which of the following is 'better'?

  # Assume nil.to_i is not available
  def foo( bar, jim )
    bar = 0 if bar.nil?  # explicit setting
    a   = bar.to_i * 2
    b   = jim.to_i * 2   # I want it to blow up if jim is nil
  end

  # Assume nil.to_i is available
  def foo( bar, jim )
    a = bar.to_i * 2   # Magically treat nil as zero

    raise "Jim can't be nil!" if jim.nil?
    b = jim.to_i * 2
  end

If the fitness criterion for 'better' in this case is 'less lines of
code', then it depends on which case is more prevalent. If the fitness
criterion is instead 'safer', then not having to_i seems to make sense
to me. If the fitness criterion is 'more convenient' or 'more
expected', then having to_i makes sense to those for whom 0 is a
reasonable integer representation of nil.

If I were to advocate removing nil.to_i, I would probably advocate
removing nil.to_s for the same reasons...and then I would really,
really hate life in the Rails world (and in other string interpolation
areas). For that reason alone I can't personally vote for getting rid
of nil.to_i.