Dear Rubyists,
def x() yield rescue :error end
[ x { Integer(nil) }, x { Float(nil) }, x{ String(nil) } ]
=> [0, :error, “”]
Isn’t that a bit inconsistent?
Cheers,
Christoffer S. wrote:
Dear Rubyists,
def x() yield rescue :error end
[ x { Integer(nil) }, x { Float(nil) }, x{ String(nil) } ]
=> [0, :error, “”]
Isn’t that a bit inconsistent?
Is this better?
irb(main):003:0> nil.to_i
=> 0
irb(main):004:0> nil.to_f
=> 0.0
irb(main):005:0> nil.to_s
=> “”
Cheers
robertOn 8/23/06, Robert K. [email protected] wrote:
Is this better?
irb(main):003:0> nil.to_i
=> 0
irb(main):004:0> nil.to_f
=> 0.0
irb(main):005:0> nil.to_s
=> “”
Well, I’d say that it confirms that the original case is an
inconsistency.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On 8/24/06, David V. [email protected] wrote:
Probably.
But my Java-addled brain makes me make damn sure nulls / nils don't come anywhere near I expect actual data, like into collections or numbers. If you don't rely on automagical conversion to work, it can't bite you if it doesn't. Just code explicitly.
That’s definitely a valid point, but slightly irrelevant.
The to_foo and #Foo() type conversion methods being different always
confuses the heck of me, which is why I get paranoid around them. Does
anyone have a link to some rationale for and explanation of the difference?
Integer/Float are usually considered to be the strict equivalents of
to_i/to_f. Try to feed them non-number strings and you’ll see. I don’t
know anything more about them though. 
Anyway, I was a bit puzzled over these two things on Integer/Float:
- Them accepting nil at all
- The (IMHO) inconsistency
I can accept both things as they are, since nothing says they should
act the way I except them to, but I thought it could be good to bring
it up.
Cheers,
Christoffer S. wrote:
Probably.
But my Java-addled brain makes me make damn sure nulls / nils don't come anywhere near I expect actual data, like into collections or numbers. If you don't rely on automagical conversion to work, it can't bite you if it doesn't. Just code explicitly.The to_foo and #Foo() type conversion methods being different always
confuses the heck of me, which is why I get paranoid around them. Does
anyone have a link to some rationale for and explanation of the
difference?
David V.
On 8/28/06, Christoffer S. [email protected] wrote:
That’s definitely a valid point, but slightly irrelevant.
Well it is your thread but I understand and agree with David that the
nil
(do not call it null on that list though 
in a conversion is troubeling.
I read him that way that by banning it a part of your inconsistency will
go
away, do you agree?
The to_foo and #Foo() type conversion methods being different always
confuses the heck of me, which is why I get paranoid around them. Does
anyone have a link to some rationale for and explanation of the
difference?Integer/Float are usually considered to be the strict equivalents of
to_i/to_f.
Are they? So far I have never heared that claim.
module Kernel - RDoc Documentation says the
contrary.
I do not necessarily think that is good, but that is how it is
documented.
Try to feed them non-number strings and you’ll see.
No you will not, “x”.to_i Integer(“x”)
I don’t
know anything more about them though.
Anyway, I was a bit puzzled over these two things on Integer/Float:
- Them accepting nil at all
- The (IMHO) inconsistency
I can accept both things as they are, since nothing says they should
act the way I except them to, but I thought it could be good to bring
it up.
I too hope that behavior will go away.
Cheers,
–
Christoffer S.
http://vemod.net/
Robert
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.
- Albert Einstein
Hello!
On 8/28/06, Robert D. [email protected] wrote:
That’s definitely a valid point, but slightly irrelevant.
Well it is your thread but I understand and agree with David that the nil
(do not call it null on that list though
in a conversion is troubeling.
I read him that way that by banning it a part of your inconsistency will go
away, do you agree?
Yes, I agree. (But the inconsistency is still there.)
Just for the record, I discovered the behaviour when using FasterCSV
(that emits nil for empty cells) and Integer(x) as a kind of
assertion.
module Kernel - RDoc Documentation says the contrary.
I do not necessarily think that is good, but that is how it is documented.
When discussing this issue on #ruby-lang the general concensus was
that Integer/Float are indeed stricter versions of to_i/to_f. The
Pickaxe says “A call to Integer will work wonders (and will throw an
exception if the input isn’t a well-formed integer)”. I should also
note that the documentation for Kernel#Integer in the Pickaxe actually
has “Integer(nil) => 0” as an example.
Try to feed them non-number strings and you’ll see.
No you will not, “x”.to_i Integer(“x”)
“x”.to_i => 0
Integer(“x”) # ArgumentError: invalid value for Integer: “x”
Isn’t that just what I meant?
it up.
I too hope that behavior will go away.
Thanks,