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
Nasir Khan 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.
--
Phlip
Test Driven Ajax (on Rails) [Book]
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
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:
<code>
n = 4
n.downto(0) do |k|
puts "#{k} bottle#{'s' if k != 1} of beer"
end
</code>
<result>
4 bottles of beer
3 bottles of beer
2 bottles of beer
1 bottle of beer
0 bottles of beer
</result>
Regards, Morton
On Sep 7, 2007, at 2:44 PM, Nasir Khan wrote:
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_sAn 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?
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 Glaesemann
grzm seespotcode net
On Sep 7, 2007, at 15:11 , Morton Goldberg wrote:
On Sep 7, 2007, at 2:44 PM, Nasir Khan wrote:
IMHO nil.to_s => "", nil.to_i => 0 and nil.to_a => are potential sources
of confusion and bugs.<code>
n = 4
n.downto(0) do |k|
puts "#{k} bottle#{'s' if k != 1} of beer"
end
</code>
Michael Glaesemann 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
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.
Of course. Thanks, Simon 
Michael Glaesemann
grzm seespotcode net
On Sep 7, 2007, at 16:45 , Simon Kröger wrote:
p proc{|k| 's' if k != 1}.call(1) #nil