Nil.to_s != "nil"

Ruby
1

Is it possible to change NilClass#to_s to return “nil”
rather than “” since “” != nil?

2

Eero S. wrote:

Is it possible to change NilClass#to_s to return “nil”
rather than “” since “” != nil?

– test.rb BEGIN
p nil.to_s.nil?

class NilClass
def to_s
nil
end
end

p nil
p nil.to_s.nil?
– test.rb END

$ ruby test.rb
false
nil
true

3

Eero S. wrote:

Is it possible to change NilClass#to_s to return “nil”
rather than “” since “” != nil?

#!/usr/bin/ruby -w

class NilClass
def to_s
return “nil”
end
end

p nil.to_s

“nil”

You may not want to do this. There might be a reason for the present
behavior. But it is very easy to do, as are all such changes in Ruby.

4

On 2006.10.27 13:56, Dmitri P. wrote:

def to_s
nil
true

I should have been clearer. I was wondering if it could
be fixed in the language itself :slight_smile: Thank you though!

5

Eero S. wrote:

Is it possible to change NilClass#to_s to return “nil”
rather than “” since “” != nil?

  1. #to_s should always return a string.
  2. Any string representation will always be a truth value.

The same situation exists for false:
!!false.to_s #=> true

You are correct that “” != nil, but “nil” != nil also.
What are you really trying to achieve? And, did you know that
nil.inspect yields “nil”?

6

Paul L. wrote:

def to_s

I don’t know what the real reason is, but it can be very useful when
interpolating strings to have it be “”

-Justin

7

On 2006.10.28 00:20, Phrogz wrote:

Eero S. wrote:

Is it possible to change NilClass#to_s to return “nil”
rather than “” since “” != nil?

  1. #to_s should always return a string.

Right.

  1. Any string representation will always be a truth value.

Yep.

The same situation exists for false:
!!false.to_s #=> true

true.to_s # => “true”
false.to_s # => “false”
nil.to_s # => “”

“” is not a valid representation of nil. “nil” is.

You are correct that “” != nil, but “nil” != nil also.
What are you really trying to achieve? And, did you know that
nil.inspect yields “nil”?

Yes. I want consistency.

8

On Sat, Oct 28, 2006 at 01:35:48AM +0900, [email protected] wrote:

“but this is a #{ problem }”

problem = ‘’

“is it really a #{ problem }?”

Of course there’s tons of code out there that relies on nil.to_s being
the empty string. I don’t expect it will change anytime soon.

9

Eero S. wrote:

On 2006.10.28 00:20, Phrogz wrote:

You are correct that “” != nil, but “nil” != nil also.
What are you really trying to achieve? And, did you know that
nil.inspect yields “nil”?

Yes. I want consistency.

It is consistent. “to_s” returns a string representation of the
value(s) of the object you call it on.

The value of the object nil is nothing and the empty string is a
sensible representation of that.

Vidar

10

On Sat, 28 Oct 2006, Eero S. wrote:

You are correct that “” != nil, but “nil” != nil also.
What are you really trying to achieve? And, did you know that
nil.inspect yields “nil”?

Yes. I want consistency.

problem = nil

“but this is a #{ problem }”

-a

11

Eero S. wrote:

You are correct that “” != nil, but “nil” != nil also.
What are you really trying to achieve? And, did you know that
nil.inspect yields “nil”?

Yes. I want consistency.

Ruby’s behavior is consistent:

“a” + nil.to_s

=> “a”

1 + nil.to_i

=> 1

1.0 + nil.to_f

=> 1.0

[1] + nil.to_a

=> [1]

nil.to_X always returns the neutral element for #+. Of course Matz could
have chosen some other kind of consistency instead of this one.

12

On Oct 28, 2006, at 3:05 PM, Vidar H. wrote:

value(s) of the object you call it on.

The value of the object nil is nothing and the empty string is a
sensible representation of that.

As well as sensible, it can be useful:

#! /usr/bin/env ruby -w

def bottles(n)
“#{n} bottle#{‘s’ if n != 1} of beer on the wall”
end

bottles(99) # => “99 bottles of beer on the wall”
bottles(1) # => “1 bottle of beer on the wall”

Regards, Morton

13

On 10/28/06, Logan C. [email protected] wrote:

Of course there’s tons of code out there that relies on nil.to_s being
the empty string. I don’t expect it will change anytime soon.

Besides, we already have syntax that prevents this from being terribly
ugly anyway.

@foo = “”
=> “”
@foo.nil?
=> false
@foo.empty?
=> true

I like knowing the difference between an empty string and an undefined
value.