nil.to_i returning zero

[Gerardo Santana Gómez Garrido]

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 =3D> 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 =3D 0 if bar.nil? # explicit setting
a =3D bar.to_i * 2
b =3D 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 =3D 0)
a =3D bar.to_i * 2
b =3D 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 =3D bar.to_i * 2 # Magically treat nil as zero

raise "Jim can't be nil!" if jim.nil?
b =3D 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.

--=20
Gerardo Santana

 

[Chad Perrin]

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

It's nil.to_i I'm uncomfortable with

Why the difference? Doesn't "" (the output of nil.to_s) evaluate to
true in a boolean context, too?

irb

irb(main):001:0> foo = nil.to_s
=> ""
irb(main):002:0> puts "true" if foo
true
=> nil

That seems to be the exact same problem cited for nil.to_i, as far as I
can tell.

 

[Gerardo Santana Gómez Garrido]

What purpose do you propose for nil if it isn't differentiated in
behavior from false in that manner? Shouldn't we then either replace all
instance of false with nil or all instances of nil with false?

I'm sorry, I didn't understand your questions.

No . . . 0 would evaluate as 0 or true, while nil would evaluate as
false. Similarly, "1" evaluates as "1", but "1".to_i evaluates as 1.
That's the point of a method like to_i, as far as I can tell.

Dismiss that paragraph please. Somehow it got chopped. I can't even
remember what was my point there Sorry.

Trans made the point that eliminating to_i from the nil lineup of methods
would suddenly result in a lot of ( x ? x.to_i : 0 ) being used. It
seems to me that nil.to_i is convenient, makes a certain amount of
logical sense, and doesn't actually introduce unexpected behavior except
in pathological edge-cases. Am I missing some non-pathological, non-edge
cases?

I think it's a matter of taste then?

If you read the pages I linked to in my first post you'll see that
nil.to_i => 0 was unexpected by some people. Even a Ruby on Rails
developer was bitten by that.

. . .

What?

Sometimes I have a problems with your language. What does that ellipsis mean?

 

[mortee]

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

Oh, c'mon ...

For some weird reason, I don't *exactly* understand your counter-argument.

mortee

 

[Phrogz]

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

Ah, but that's subtly different for the edge case where nil is
explicitly passed in:
irb(main):001:0> def foo( bar=0 ) bar end
=> nil
irb(main):002:0> foo()
=> 0
irb(main):003:0> foo( nil )
=> nil

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

I don't understand your reasoning (though I understand what
serialization is). It seems to me like you are saying "NilClass#to_i
has the meaning xxx, NilClass.to_s has the meaning yyy, and these are
different from what it 'means' to use Float#to_i or Float#to_s." I
would say this, instead:

AnyClass#to_xxx should return an instance of some class (related to
xxx) that is somehow logically related to this particular instance. It
doesn't matter what AnyClass is, or what xxx is. There is no inherent
meaning in the method beyond that. It's not intended to be used for
one thing (serialization) or another (boolean tests). The only
requirement for adding such a method is that some reasonable
justification can be made for why an instance of class 'xxx' can be
created from an instance of AnyClass.

(It would not make much sense, IMO, to add FalseClass#to_hash or a
Float#to_a, because there does not seem to be a logical transformation
from the instance of one class to an instance of the other.)

I would say that a reasonable argument can be made that 0 (the
instance of the Integer/Fixnum class) is a reasonable result if I
asked for nil.to_i.

I wouldn't. See reason above.

I think I'm missing your major argument then.
Is your argument: "NilClass#to_i should be removed because it's
dangerous; I might call it by accident, and get a result instead of an
error." If so, I think the same argument applies equally to #to_s.

# If these variables haven't been initialized,
# I want an error, not empty strings breaking
# my output!!!
puts "Hello, #@firstname #@lastname"

To be clear, though, I'm *not* advocating removing NilClass#to_s. It
provides a reasonable (and usually helpful) string representation of a
nil value.

If I am worried about nil values:
raise "SET NAMES FIRST" if @firstname.nil? || @lastname.nil?
puts "Hello, #@firstname #@lastname"

If you are concerned that someone might explicitly pass you a nil
value when you were expecting something that could be transformed to
an integer, you can do the same. Or, as already suggested, you can do
this:

irb(main):004:0> class NilClass; undef :to_i; end
=> nil
irb(main):005:0> nil.to_i
NoMethodError: undefined method `to_i' for nil:NilClass
from (irb):5

Of course, that's a workaround, and what you're trying to do is
improve the language for everyone based on what you think makes more
sense. I simply reiterate that suggestion because it is a possibility
of the majority of people (or Matz himself) disagrees with you.

 

[Phrogz]

For some weird reason, I don't *exactly* understand your counter-argument.

I suspect that what Gerardo was intending to convey was:

"Oh, c'mon... I'm telling you that I think the language should be
changed, and you're telling me how I can change it just for me. That's
not really my point. You say 'everyone else', but you don't provide
any basis for that statistic. I've known experienced Rails developers
who were surprised and burned by this, so your argument is specious.
Please stick to discussing the merits of my arguments, and whether or
not my proposal makes sense *for everyone*. How would you like it if
every time you found a problem with the language and attempted to
discuss it people just stuck their heads in the sand and yelled, 'Ruby
is perfect! Everyone thinkgs so! If you think otherwise, you must be a
nut; go modify the behavior of the core classes yourself and leave us
sane people alone!'"

I'm just guessing, though.

 

[Rick DeNatale]

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

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 ||=3D 0
a +=3D 1

To be just
a +=3D 1


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

--=20
Rick DeNatale

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

 

[Chad Perrin]

I'm sorry, I didn't understand your questions.

nil.to_i => 0
if 0 => true
nil.to_s => ""
if "" => true
false.to_i => NoMethodError: undefined method `to_i' for false:FalseClass
false.to_s => "false"
if "flase" => true

The only difference in evaluation is to_i. You propose removing that
difference. Why, then, should we have both at all?

Dismiss that paragraph please. Somehow it got chopped. I can't even
remember what was my point there Sorry.

Uh . . . I have no idea how that happened.

Anyway, my comment was in response to the sentence starting "Under" and
ending "does."

I think it's a matter of taste then?

If you read the pages I linked to in my first post you'll see that
nil.to_i => 0 was unexpected by some people. Even a Ruby on Rails
developer was bitten by that.

I've been bitten by forgetting to use to_i on a couple of occasions, too.
I don't blame the language, though.

What?

Sometimes I have a problems with your language. What does that ellipsis mean?

In this case, it means I don't know how to answer your question without
just repeating myself. For clarification: no, not just an accumulator
(though that is one instance that might fit the description I provided).
Sometimes, keeping a count of something also involves entering totals
rather than deltas, for instance.

 

[Jörg W Mittag]

In fact, I'm almost ready to go out on the limb and suggest that it
might be nice if: [NilClass implemented +, -, *, /] [...]
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.

This is just an example of how easy it is to do the Null Object
Refactoring in Ruby. Another nice one is

class NilClass; def []; nil end end

which allows things like @potentially_nil[1][:foo][:bar] to return nil
instead of throwing a NoMethodError.

I must admit that I don't really understand the OPs position. My
interpretation is as follows:

(1) nil *is not* false, but, when used in a Boolean context,
one can generally reasonably *interpret* nil to be
somewhat similar to false, without screwing up Boolean
semantics too much.

(2) nil *is not* 0, but, when used in a numerical context,
one can generally reasonably *interpret* nil to be
somewhat similar to 0, without screwing up numerical
semantics too much.

To me, (1) and (2) are *exactly* the same, but for some reason the OP
seems to be perfectly comfortable with (1) but violently opposed to
(2), and I don't understand what the difference is.

The *whole point* of having a full fledged nil object like in Ruby or
Smalltalk (or Haskell), as opposed to some null pointer like in C,
C++, C# or Java, is, that my program *doesn't* blow up if I'm dealing
with a nil. In C, NULL is invalid. In Java, null is invalid, it isn't
even an object, it doesn't really exist. When I try to evaluate null
in a Boolean context in Java, I don't get false like I would in Ruby,
I get a NullPointerException and my program terminates. In C,
accessing a NULL pointer will generally not even gracefully terminate
but simply crash the program. That is precisely what a full fledged
nil object avoids, so, to me, it makes perfect sense that said object
can be reasonably used in a variety of contexts, without crashing or
throwing exceptions.

That is not to say, that nil.to_i returning 0 is *always* right! I do
believe however, that nil.to_i throwing an exception is almost always
wrong and that returning 0 is generally right. If, however, I want to
multiply a series of values, some of which might be nil, it would make
sense to redefine nil.to_i to return 1 (because it is the neutral
element of multiplication) instead of 0 and/or additionally
(re)defining nil.* to return its argument. Similarly for to_s: in a
report generator, it might make sense to redefine nil.to_s to return
"N/A" instead of the empty string, in a HTML table generator to return
" ", in a debugger to return "nil" and so on. Sometimes it might
even make sense to define method_missing to always return nil and
never throw a NoMethodError.

Heck, in some twisted situation it might even be desirable to be able
to make nil evaluate to true in a boolean context (after all, true
*is* the neutral element of conjunction), althought that is
unfortunately not possible in Ruby.

I hope that makes some sense and explains why it might be desirable
and sensible to be able to send messages to nil, convert nil to other
types and use nil in different contexts without having to worry about
exceptions or crashes.

jwm

 

[hadley wickham]

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 ||=3D 0
a +=3D 1

To be just
a +=3D 1

Why is addition so special? What about multiplication and division?

Really, you probably want nil to be the idempotent element for any
operation (ie. f(a, nil) =3D a). But can you implement that? Probably
not.

Hadley

--=20
http://had.co.nz/

 

[John Joyce]

J=F6rg put it well.
nil in Ruby is very useful.
nil has methods that are convenient.
Most singletons have very convenient methods.
If nil.to_i bothers you, you might consider that your objects or =20
algorithms are off the Ruby way.
It is entirely convenient and useful sometimes to have a to_i for nil =20=

and that it should be zero.
It doesn't mean that :
nil =3D=3D 0
it means :
nil.to_i =3D=3D 0

Not:
nil < 1
but:
nil.to_i < 1

Convenience method.
In most cases nil will cause an unexpected nil object error.=

 

[Robert Dober]

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 ||=3D 0
a +=3D 1

To be just
a +=3D 1


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

Please let me help you with this then

The consequences would be that you code gets much more difficult to debug.
Now that is not necessarily a reason not to do it, Thomas just boldly
said "bah that's what tests are for", this is a respectable POV, I
however feel that not everybody in this discussion is aware of the
fragility that may include into the code.
Personally I would prefer not to pay that price, many are prepared to
pay it, so they are probably not completely wrong .

Let us have some fun with OO now, again that is not an argument for or
against, I just want to look at it from yet another angle:
What would one esteem the responsibilities of NilClass ?
To convert itself to 0, to "", to reply to messages like "+"?
Again I see your point, what elegant code that would be
@a +=3D 1
then of course
@a.to_h[x] =3D2 # as suggested by Thomas too
But again elegance comes with a price in robustness.

But wait a minute why do String and Integer get favorite treatement by NilC=
lass
I want NilClass to do the same thing for Arrays and Hashes
@a << {:a =3D> 42} instead of (@a||=3D{}).update :a =3D> 42
@a << :a instead of (@a||=3D[]) << :a
hmm are the former really that better than the later?

I just finished KentBeck's Smalltalk Pattern Best Practices and I have
therefore much
difficulties to sacrifice "Readability" for "Elegance". But it would
make programming
more fun, sure .

I honestly believe that NilClass' responsibilities shall not be that
large, but it is indeed an interesting discussion.

--
Rick DeNatale

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

Cheers
Robert
--=20
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/

 

[Rick DeNatale]

Why is addition so special? What about multiplication and division?

Note that I did give implementations of NilClass#* and NilClass#/
which treat nil as 0. I just didn't give an example.

Really, you probably want nil to be the idempotent element for any
operation (ie. f(a, nil) = a).

Don't think so, at least for - and /, if you want to go in that
direction though I think that it should be:

nil + x => x
nil - x => -x
nil * x => x
nil / x => 1 / x

On the other hand, this does seem inconsistent with nil.to_i being 0.

But can you implement that? Probably
not.

For the 4 arithmetic operators certainly.

 

[Rick DeNatale]

Please let me help you with this then

The consequences would be that you code gets much more difficult to debug.

I don't know that this is necessarily true.

I'm not coming up with an example of code which this makes harder to
debug, but that might just be a lack of imagination on my part.

Now that is not necessarily a reason not to do it, Thomas just boldly
said "bah that's what tests are for", this is a respectable POV, I
however feel that not everybody in this discussion is aware of the
fragility that may include into the code.
Personally I would prefer not to pay that price, many are prepared to
pay it, so they are probably not completely wrong .

What price? Writing tests? Tests are an investment. Test driven
development is what enables writing agile quality code in dynamic
languages. Some would argue that it's a superior replacement for
static typing, and I'd be one of those.

Let us have some fun with OO now, again that is not an argument for or
against, I just want to look at it from yet another angle:
What would one esteem the responsibilities of NilClass ?

I just finished KentBeck's Smalltalk Pattern Best Practices and I have
therefore much
difficulties to sacrifice "Readability" for "Elegance". But it would
make programming
more fun, sure .

Ah, but readability is language dependent. To make an analogy,
Chaucer, Shakespeare, Voltaire, and Hemingway are all readable to
various degrees depending on the reader, and his familiarity with
different language and literature.

Kent's book is very strongly rooted in Smalltalk and in the
capabilities of the typical Smalltalk IDE (primarily VisualWorks and
VisualAge at the time the book was written). A number of his
patterns deal with doing things which maximize the ability to read the
code using browser facilities.

Pattern's don't live in a vacuum, the choice of patterns is affected
by environmental pressures, and the language is a major contributor to
these pressures.

I'm pretty sure that Kent would agree with this. Kent's all about
carefully choosing patterns.

Here's another Kent Beckism, with no intended connection to anything
said on this thread. Yesterday I watched a video of a recent panel
chaired by Martin Fowler on the infoq site. Martin put together a
collection of senior ThoughtWorks consultants to discuss the
relationship of design to agile methods. One gave an example of a
project which got off on the wrong track by making a simplifying
assumption which caused much grief when the app needed to be scaled to
large numbers of concurrent users.

it was pointed out that this was a counterexample to Kent's "Do the
simplest thing that could possibly work." Martin pointed out that
simplicity often requires a deal of thought. He quoted Kent who in a
similar situation was heard to say, "I didn't say the stupidest thing
that could possibly work!"

Cheers!

 

[Robert Dober]

Good Rick never good fight with you, always agreed, now we can go for it

I don't know that this is necessarily true.

I'm not coming up with an example of code which this makes harder to
debug, but that might just be a lack of imagination on my part.

Well I always forget to initialize my ivars and I get bitten late, I
guess if nil responds to messages it will take me about 10mins longer
to find the error (on average) but
extreme cases exist .

What price? Writing tests? Tests are an investment. Test driven
development is what enables writing agile quality code in dynamic
languages. Some would argue that it's a superior replacement for
static typing, and I'd be one of those.

Completely agree with you here, that was *not* the prize I was thinking about.
I was rather thinking about robustness and readability and *maintainability*.

Ah, but readability is language dependent. To make an analogy,
Chaucer, Shakespeare, Voltaire, and Hemingway are all readable to
various degrees depending on the reader, and his familiarity with
different language and literature.

But they do not mean to be maintained LOL, let us just rewrite Hamlet
for our new
customer -- wait a minute these things happen too.
Yeah readability is relative as in art, but programming is an art....

Kent's book is very strongly rooted in Smalltalk and in the
capabilities of the typical Smalltalk IDE (primarily VisualWorks and
VisualAge at the time the book was written). A number of his
patterns deal with doing things which maximize the ability to read the
code using browser facilities.

Very true indeed, but that only means we need a Ruby Browser

Pattern's don't live in a vacuum, the choice of patterns is affected
by environmental pressures, and the language is a major contributor to
these pressures.

I'm pretty sure that Kent would agree with this. Kent's all about
carefully choosing patterns.

Yeah but he clearly said it "communicating code" comes first, and I believe that
defining all that kind of messages for nil is not in this spirit, but
this is a Strong View
Weekly Hold (if you see what I mean .

Here's another Kent Beckism, with no intended connection to anything
said on this thread. Yesterday I watched a video of a recent panel
chaired by Martin Fowler on the infoq site. Martin put together a
collection of senior ThoughtWorks consultants to discuss the
relationship of design to agile methods. One gave an example of a
project which got off on the wrong track by making a simplifying
assumption which caused much grief when the app needed to be scaled to
large numbers of concurrent users.

it was pointed out that this was a counterexample to Kent's "Do the
simplest thing that could possibly work." Martin pointed out that
simplicity often requires a deal of thought. He quoted Kent who in a
similar situation was heard to say, "I didn't say the stupidest thing
that could possibly work!"

Well understood but sometimes you just cannot anticipate things and
not wasting time by trying is a clever thing, anyway that is not
really related I agree.

I guess I am against nil.to_i etc. because I tend to abuse of these
and want to be proteced (kidding).
Cheers
R.

 

[Rick DeNatale]

Good Rick never good fight with you, always agreed, now we can go for it

Well I always forget to initialize my ivars and I get bitten late, I
guess if nil responds to messages it will take me about 10mins longer
to find the error (on average) but
extreme cases exist .

But the idea of allowing

a += 1

to set a to 1 when it's currently nil, just seems to me to be a nice
enhancement to the lazy initialization 'pattern' fitting in with the
well-known ruby lazy initialization idiom

a ||= 1

When I first saw that last when I first encounterd Ruby, I smiled,
realizing how much more I liked it than what I'd typed so many times
in the past

a isNil ifTrue:[a := 1]

Which you should recognize from p. 85 of Kent's SBPP.

 

[Robert Dober]

Good Rick never good fight with you, always agreed, now we can go for it

Well I always forget to initialize my ivars and I get bitten late, I
guess if nil responds to messages it will take me about 10mins longer
to find the error (on average) but
extreme cases exist .

But the idea of allowing

a += 1

to set a to 1 when it's currently nil, just seems to me to be a nice
enhancement to the lazy initialization 'pattern' fitting in with the
well-known ruby lazy initialization idiom

a ||= 1

When I first saw that last when I first encounterd Ruby, I smiled,
realizing how much more I liked it than what I'd typed so many times
in the past

a isNil ifTrue:[a := 1]

Which you should recognize from p. 85 of Kent's SBPP.

LOL I guess I know that much Smalltalk, it is indeed an idiom which can be
defined as APITA.
No do not take me wrong I do accept that the world has moved on in the last 10
years but sometimes I am torn apart between expressiveness and elegance.

I do traditionally have difficulties to like new idioms, so I will
give in somehow,
Nevertheless one question remains, where is the border between
a += 1
a << 3
a << ( :a=>42 )
a << ?a
a += "a"

a <x>= any_object for
if a then a = a+ any_object
else
a = Nil.__ex_nihilis__( <x>, any_object )
end

and everybody can define Nil.__ex_nihilis__ as pleases her ?

that is weird.
R.

 

[Rick DeNatale]

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 <x>= any_object for
if a then a = a+ any_object
else
a = Nil.__ex_nihilis__( <x>, 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#+

 

[Robert Dober]

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

Reasonable choice I have to admit

And going a bit too far I would say.

ok that was actually what I wanted you hear saying

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

But how would you implement
a +=1 for a being nil?

 

[Dirk Traulsen]

Am 17 Oct 2007 um 16:31 hat Robert Dober geschrieben:

Reasonable choice I have to admit

I think this is a reasonable proposal:

class NilClass
def +(obj)
obj
end
end

Can you think of any case in which this poses a problem?
It should be universally true.