Nil.to_s != "nil"

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

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

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.

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!

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

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

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.

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.

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

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

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.

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

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs