Integer(nil) versus Float(nil) versus String(nil)

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 Sawicki
http://vemod.net/

Christoffer Sawicki 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

  robert

Christoffer Sawicki 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?

Cheers,

Probably.

<rant>
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.
</rant>

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 Vallner

Well, I'd say that it confirms that the original case is an inconsistency.

···

On 8/23/06, Robert Klemme <shortcutter@googlemail.com> wrote:

Christoffer Sawicki 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
=> ""

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Probably.

<rant>
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.
</rant>

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. :slight_smile:

Anyway, I was a bit puzzled over these two things on Integer/Float:

1) Them accepting nil at all
2) 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,

···

On 8/24/06, David Vallner <david@vallner.net> wrote:

--
Christoffer Sawicki
http://vemod.net/

> Probably.
>
> <rant>
> 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.
> </rant>

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 :wink:
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.
http://www.ruby-doc.org/core/classes/Kernel.html#M002003 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. :slight_smile:

Anyway, I was a bit puzzled over these two things on Integer/Float:

1) Them accepting nil at all
2) 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 Sawicki
http://vemod.net/

Robert

···

On 8/28/06, Christoffer Sawicki <christoffer.sawicki@gmail.com> wrote:

On 8/24/06, David Vallner <david@vallner.net> wrote:

--
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!

>
> > Probably.
> >
> > <rant>
> > 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.
> > </rant>
>
> 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 :wink:
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.) :slight_smile:

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.

> 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.
http://www.ruby-doc.org/core/classes/Kernel.html#M002003 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?

> I don't
> know anything more about them though. :slight_smile:
>
> Anyway, I was a bit puzzled over these two things on Integer/Float:
>
> 1) Them accepting nil at all
> 2) 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.

Thanks,

···

On 8/28/06, Robert Dober <robert.dober@gmail.com> wrote:

On 8/28/06, Christoffer Sawicki <christoffer.sawicki@gmail.com> wrote:
> On 8/24/06, David Vallner <david@vallner.net> wrote:

--
Christoffer Sawicki
http://vemod.net/