Nil.to_s

Ruby
1

IMHO nil.to_s => “”, nil.to_i => 0 and nil.to_a => [] are potential
sources
of confusion and bugs.

If anywhere in your code you have statement like

x = y.to_s then you will have to be careful to replace it with
x = y.nil? ? nil : y.to_s

An empty string equivalence of nil seems untuitive to me, all of these
should just return nil.
Is it just me or are there others who have also feel like this?

Thanks
Nasir

2

Nasir K. wrote:

IMHO nil.to_s => “”, nil.to_i => 0 and nil.to_a => [] are potential
sources
of confusion and bugs.

nil is a potential source of confusion and bugs. Ideally, a method
should
not be called, or it should be called with only relevant data. That’s
the
goal of your high-level designing; look up “Null Object Refactor” to
learn
good tips there.

After you allow nils into your equations, you already have the potential
source of confusion and bugs…

If anywhere in your code you have statement like

x = y.to_s then you will have to be careful to replace it with
x = y.nil? ? nil : y.to_s

Google for my illustrious street name, “relevant”, and “relevance”, all
with
separate sets of quotes (to prevent stemming). My projects use a cute
little
patch on NilObject which takes care of that exact situation:

x = y.relevance

Is it just me or are there others who have also feel like this?

Ruby’s nil handling is exceptionally clean and useful, compared to other
languages. Some, for example, allow 0 to behave as ‘false’. That would
be
bogus in Ruby because 0 is not nil, and nil does behave as false. So
we
allow statements like (x || ‘’) to perform intuitively, without
cluttering
our methods up with excessive ‘if’ statements.

The price of these conveniences is (x || ‘’) is not as costly as it
should
be. Our programs should have fixed x before they got to this point. But
Ruby
gives the short-term bandaid a lower cost than the long-term cure.

3

On Sep 7, 2007, at 2:44 PM, Nasir K. wrote:

should just return nil.
Is it just me or are there others who have also feel like this?

This has come up on the mailing list before, and there are some
people who agree with you. I, for one, prefer it the way it is
because it lets me write code like:

n = 4 n.downto(0) do |k| puts "#{k} bottle#{'s' if k != 1} of beer" end 4 bottles of beer 3 bottles of beer 2 bottles of beer 1 bottle of beer 0 bottles of beer

Regards, Morton

4

Michael G. wrote:

As I read it, OP is asking specifically about the behavior of
nil.to_(s|i|a). I may be missing something, but where does this code
involve nil? k is in 4…0, but not nil.

p proc{|k| ‘s’ if k != 1}.call(1) #nil

cheers

Simon

5

It’s this way with every language. You will find things you like and
things you don’t like.
One reason Ruby’s approach to nil is odd to lots of people is that
they’re used to other languages that don’t take this approach.
Ruby’s approach to nil is extremely convenient and useful.

6

On Sep 7, 2007, at 16:45 , Simon Kröger wrote:

p proc{|k| ‘s’ if k != 1}.call(1) #nil

Of course. Thanks, Simon :slight_smile:

Michael G.
grzm seespotcode net

7

On Sep 7, 2007, at 15:11 , Morton G. wrote:

end

As I read it, OP is asking specifically about the behavior of nil.to_
(s|i|a). I may be missing something, but where does this code involve
nil? k is in 4…0, but not nil.

For the record, I don’t have any issue with how Ruby handles nils in
this case. I’m just commenting on this particular response.

Michael G.
grzm seespotcode net