Nil.to_i returning zero

Ruby
41

On 10/17/07, Dirk T. [email protected] wrote:

Can you think of any case in which this poses a problem?
Hmm, let me see
a = [42]
b += a
b << [43] ouch that hurts

maybe
class NilClass
def + obj
obj.clone rescue obj
end
end
Cheers
Robert

42

On 10/16/07, Robert D. [email protected] wrote:

Nevertheless one question remains, where is the border between
a += 1
a << 3
a << ( :a=>42 )
a << ?a

For these I’d draw the border at mutating operators.

a += “a”

Being a pragmatic, this doesn’t bother me. It falls into the same
place as things like,

(1.4…10.0).to_a

and

[:a, :b].sort # This fails for Ruby < 1.9 anyway
or
[“My left shoe”, Time.now].sort

a = any_object for
if a then a = a+ any_object
else
a = Nil.ex_nihilis( , any_object )
end

and everybody can define Nil.ex_nihilis as pleases her ?

that is weird.

And going a bit too far I would say.

Afer all I wasn’t even necessarily prepared to push for NilClass#+

–
Rick DeNatale

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

43

Am 17 Oct 2007 um 21:08 hat Robert D. geschrieben:

Can you think of any case in which this poses a problem?
end
end

You’re right. That’s really better.
(You didn’t have to look too hard for a problem, did you? :slight_smile: Sometimes
I’m blind! )

But in earnest, I really think this would be a good thing to have in
Ruby.

I’m not so sure about the other cases *,- and /. There you would have
to make a not so short list of object classes for which they must be
handled differently.

But not for +, there it is very clear:
nothing + x is always x, independant from the nature of x.

So, as this is universally correct, it could go in Ruby itself.

44

nil is an interesting beast. In one of my projects, I added “each” to
NilClass

class NilClass
def each
end
end

so that I can treat nil returned from IO:select as if it is an empty
array.

I like this change personally, and it does make sense to me logically
(“doing something on each element of nothing” is equivalent to “do
nothing”),
but does it make sense to everybody? What if somebody fail to capture
the
bug
because of this change?

The same question applies to “nil+1”. Does it make sense to everybody?
Somebody may say “if nil+1 is 1, then, 1+nil should be 1”, then somebody
else may say “how about nil+nil”?

This may eventually become very philosophical discussion, where there is
no
single answer…

Satoshi

2007/10/17, Dirk T. [email protected]:

45

Hi –

On Thu, 18 Oct 2007, Satoshi Nakajima wrote:

I like this change personally, and it does make sense to me logically
(“doing something on each element of nothing” is equivalent to “do
nothing”),
but does it make sense to everybody? What if somebody fail to capture the
bug
because of this change?

I would definitely not make a change like that. First of all, nil
isn’t composed of elements, so there’s no concept of “each element” of
nil. Second, the answer to your second question is: the program will
almost certainly blow up or silently do something it isn’t supposed to
do. That’s what happens when you mask bugs :slight_smile: It’s not a good idea.

David