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

Discussion in 'Ruby' started by Christoffer Sawicki, Aug 23, 2006.

  1. 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, Aug 23, 2006
    #1
    1. Advertising

  2. 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
    Robert Klemme, Aug 23, 2006
    #2
    1. Advertising

  3. On 8/23/06, Robert Klemme <> 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
    > => ""


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

    --
    Rick DeNatale

    My blog on Ruby
    http://talklikeaduck.denhaven2.com/
    Rick DeNatale, Aug 23, 2006
    #3
  4. 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
    David Vallner, Aug 24, 2006
    #4
  5. On 8/24/06, David Vallner <> wrote:
    > 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. :)

    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,

    --
    Christoffer Sawicki
    http://vemod.net/
    Christoffer Sawicki, Aug 28, 2006
    #5
  6. Hello!

    On 8/28/06, Robert Dober <> wrote:
    > On 8/28/06, Christoffer Sawicki <> wrote:
    > >
    > > On 8/24/06, David Vallner <> wrote:
    > > > 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 ;)
    > 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.

    > > 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. :)
    > >
    > > 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,

    --
    Christoffer Sawicki
    http://vemod.net/
    Christoffer Sawicki, Sep 2, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andy
    Replies:
    7
    Views:
    6,238
    Roedy Green
    May 10, 2004
  2. Jim West
    Replies:
    4
    Views:
    1,400
    Jeff Schwab
    Jan 16, 2004
  3. bd
    Replies:
    0
    Views:
    604
  4. Carsten Fuchs
    Replies:
    45
    Views:
    1,504
    James Kanze
    Oct 8, 2009
  5. Paul Butcher
    Replies:
    12
    Views:
    686
    Gary Wright
    Nov 28, 2007
Loading...

Share This Page