On Tue, Oct 16, 2007 at 05:39:39AM +0900, Gerardo S. G?mez Garrido
wrote:
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.
2007/10/15, Phrogz [email protected]:
I expect to get a converted object or some Error (TypeError maybe?)
back from any to_ method. Giving me the same object back or nil
doesn’t make any sense…You got it wrong too (am I that confusing? :).
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
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.
Assume nil.to_i is not available
def foo( bar, jim )
bar = 0 if bar.nil? # explicit setting
a = bar.to_i * 2
b = jim.to_i * 2 # I want it to blow up if jim is nil
end
I would write that as:
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
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.
2007/10/15, Chad P. [email protected]:
On Tue, Oct 16, 2007 at 04:02:35AM +0900, Gerardo S. G?mez Garrido wrote:
nil has other uses besides representing nothing: it means false in a
boolean context.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.
If nil
Under that logic then zero must evaluate to false, just like C and Python does.
I don’t agree with that, of course.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.
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?
Gerardo S. Gómez Garrido wrote:
Chand Perrin wrote:
What would you expect it to return, and why would you think that should
be the expected behavior?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).
mortee wrote:
Well, if you’d like it so much, why not just redefine it in your own
programs? Everyone else seems to expect it to return 0 instead of being
hostile by throwing an exception…Oh, c’mon …
For some weird reason, I don’t exactly understand your
counter-argument.
mortee
On Oct 15, 2:39 pm, “Gerardo S. Gómez Garrido”
[email protected] wrote:
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
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 “”.
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.
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.
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.
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.
On Oct 15, 3:22 pm, mortee [email protected] wrote:
Gerardo S. Gómez Garrido wrote:
mortee wrote:
Well, if you’d like it so much, why not just redefine it in your own
programs? Everyone else seems to expect it to return 0 instead of being
hostile by throwing an exception…Oh, c’mon …
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.
On 10/15/07, mortee [email protected] wrote:
hostile by throwing an exception…
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 ||= 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.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On Tue, Oct 16, 2007 at 05:52:20AM +0900, Gerardo S. G?mez Garrido
wrote:
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?
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.”
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.
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.
On 10/15/07, Rick DeNatale [email protected] wrote:
can be represented as zero, when zero doesn’t mean false, but true.
programs? Everyone else seems to expect it to return 0 instead of being
a ||= 0
a += 1To be just
a += 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) = a). But can you implement that? Probably
not.
Hadley
Jörg 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
algorithms are off the Ruby way.
It is entirely convenient and useful sometimes to have a to_i for nil
and that it should be zero.
It doesn’t mean that :
nil == 0
it means :
nil.to_i == 0
Not:
nil < 1
but:
nil.to_i < 1
Convenience method.
In most cases nil will cause an unexpected nil object error.
Rick DeNatale wrote:
mortee wrote:
Well, if you’d like it so much, why not just redefine it in your own
programs? Everyone else seems to expect it to return 0 instead of being
hostile by throwing an exception…
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 += 1To be just
a += 1As 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
On 10/15/07, Rick DeNatale [email protected] wrote:
can be represented as zero, when zero doesn’t mean false, but true.
programs? Everyone else seems to expect it to return 0 instead of being
a ||= 0
a += 1To be just
a += 1As 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 += 1
then of course
@a.to_h[x] =2 # 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
NilClass
I want NilClass to do the same thing for Arrays and Hashes
@a << {:a => 42} instead of (@a||={}).update :a => 42
@a << :a instead of (@a||=[]) << :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 DeNataleMy blog on Ruby
http://talklikeaduck.denhaven2.com/
Cheers
Robert
On 10/15/07, hadley wickham [email protected] wrote:
On 10/15/07, Rick DeNatale [email protected] wrote:
a += 1
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
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On 10/16/07, Robert D. [email protected] wrote:
On 10/15/07, Rick DeNatale [email protected] wrote:
…time pondering the consequences.
Please let me help you with this thenThe 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 F. 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!”
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On 10/16/07, Robert D. [email protected] wrote:
On 10/16/07, Rick DeNatale [email protected] wrote:
On 10/16/07, Robert D. [email protected] wrote:
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.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On 10/16/07, Rick DeNatale [email protected] wrote:
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 thenThe consequences would be that you code gets much more difficult to debug.
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 :(.
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.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.
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 BrowserPattern’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 ;).
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.
On 10/16/07, Rick DeNatale [email protected] wrote:
I’m not coming up with an example of code which this makes harder to
to set a to 1 when it’s currently nil, just seems to me to be a niceWhich 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 = any_object for
if a then a = a+ any_object
else
a = Nil.ex_nihilis( , any_object )
end
and everybody can define Nil.ex_nihilis as pleases her ?
that is weird.
R.
On 10/16/07, Rick DeNatale [email protected] wrote:
> > that is weird. > > 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?On 10/16/07, Robert D. [email protected] wrote:
Nevertheless one question remains, where is the border between
a += 1
a << 3
a << ( :a=>42 )
a << ?aFor these I’d draw the border at mutating operators.
Reasonable choice I have to admit
Am 17 Oct 2007 um 16:31 hat Robert D. 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.
On 10/17/07, Robert D. [email protected] wrote:
Reasonable choice I have to admit
> > that is weird. > > 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?
Been there, done that
From two days ago:
class NilClass
def +(aNumber)
aNumber
end
def -(aNumber)
0 - aNumber
end
…
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs