2007/10/15, Phrogz <phrogz / mac.com>:
> On Oct 15, 1:02 pm, "Gerardo Santana Góíez 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".

Let me just precise that I'm ok with nil.to_s.

It's nil.to_i I'm uncomfortable with


>
> 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.


Not really, if we understand #to_s as a form of serialization.
nil.to_s doesn't return "nil", nor "0", but "".


> 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".

And so do I.


>
> 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


I would write that as:

  # Assume nil.to_i is not available
  def foo( jim, bar = 0)
    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 it were that case, my version is shorter.


> 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,


I wouldn't. See reason above.


> 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.
>
>
>


-- 
Gerardo Santana