idea: klass.from_s(str)

Discussion in 'Ruby' started by Eric Mahurin, Aug 25, 2005.

  1. Eric Mahurin

    Eric Mahurin Guest

    I was thinking how in seems a little asymmetric that many
    classes have #to_s method, but when you want to make one of
    those objects from a String, you have to clutter the String
    class with yet another #to_* method. So the String class gets
    the burden of all those #to_* methods. Instead, what if we
    would have the convention that creating an object from a string
    would be a class method (for the class of that object) instead
    of another String#to_* method. So, instead of these:

    String#to_i
    String#to_f
    String#to_sym
    String#to_<c> # where c is a abbreviation for the class

    you'd have these:

    Integer.from_s(str)
    Float.from_s(str)
    Symbol.from_s(str)
    klass.from_s(str)

    Maybe you'd even want to be able to convert from an inspect
    string:

    klass.from_inspect(str)

    I'm not saying that we should replace all obj.to_ methods with
    klass.from_ methods. I'm just saying to make them come in
    pairs. If you have a klass#to_* method, you should have a
    corresponding klass.from_* method if appropriate. This would
    make your class more encapsulated, instead of having some of it
    in String (or whatever class you are converting from).


    __________________________________________________
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around=20
    http://mail.yahoo.com=20
     
    Eric Mahurin, Aug 25, 2005
    #1
    1. Advertising

  2. Eric Mahurin wrote:

    > I was thinking how in seems a little asymmetric that many classes have
    > #to_s method, but when you want to make one of those objects from a
    > String, you have to clutter the String class with yet another #to_*
    > method. So the String class gets the burden of all those #to_*
    > methods. Instead, what if we would have the convention that creating
    > an object from a string would be a class method (for the class of that
    > object) instead of another String#to_* method. So, instead of these:
    >
    > String#to_i String#to_f
    > String#to_sym
    > String#to_<c> # where c is a abbreviation for the class
    >
    > you'd have these:
    >
    > Integer.from_s(str)
    > Float.from_s(str)
    > Symbol.from_s(str)
    > klass.from_s(str)


    How is

    i = Integer.from_s("123")

    better than

    i = "123".to_i?

    I prefer "send a message to the string to convert itself to something
    else" over "send a message to a class to convert the argument to an
    instance of that class",
    nikolai

    > klass.from_inspect(str)


    Kind of like read in Haskell or similar in Lisp?,
    nikolai

    --
    Nikolai Weibull: now available free of charge at http://bitwi.se/!
    Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
    main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
     
    Nikolai Weibull, Aug 25, 2005
    #2
    1. Advertising

  3. Hi --

    On Thu, 25 Aug 2005, Eric Mahurin wrote:

    > I was thinking how in seems a little asymmetric that many
    > classes have #to_s method, but when you want to make one of
    > those objects from a String, you have to clutter the String
    > class with yet another #to_* method. So the String class gets
    > the burden of all those #to_* methods.


    I don't see that as a burden. It seems to correspond precisely to
    what's happening.

    > Instead, what if we
    > would have the convention that creating an object from a string
    > would be a class method (for the class of that object) instead
    > of another String#to_* method. So, instead of these:
    >
    > String#to_i
    > String#to_f
    > String#to_sym
    > String#to_<c> # where c is a abbreviation for the class
    >
    > you'd have these:
    >
    > Integer.from_s(str)
    > Float.from_s(str)
    > Symbol.from_s(str)
    > klass.from_s(str)


    That seems like at least an equal amount of clutter -- actually more,
    since you've now got a receiver, method, and argument, where the
    argument and the method name contain the same information (String-hood
    in this case). It also introduces a whole range of scenarios
    involving wrong arguments. I prefer simply sending a conversion
    request to an object and getting its response.

    > Maybe you'd even want to be able to convert from an inspect
    > string:
    >
    > klass.from_inspect(str)
    >
    > I'm not saying that we should replace all obj.to_ methods with
    > klass.from_ methods. I'm just saying to make them come in
    > pairs. If you have a klass#to_* method, you should have a
    > corresponding klass.from_* method if appropriate. This would
    > make your class more encapsulated, instead of having some of it
    > in String (or whatever class you are converting from).


    So you'd have:

    Integer.from_f(1.0)
    Integer.from_s("1")
    Integer.from_nil(nil)
    Integer.from_i(1)

    instead of

    1.0.to_i
    "1".to_i
    nil.to_i
    1.to_i

    I'm afraid it seems circuitous and verbose to me.


    David

    --
    David A. Black
     
    David A. Black, Aug 25, 2005
    #3
  4. Joel VanderWerf wrote:

    > Nikolai Weibull wrote:


    > > i = Integer.from_s("123")


    > We already have something like that:
    >
    > irb(main):001:0> Integer("123")
    > => 123


    Yes, but it's a function and it doesn't really do very much more than
    #to_i (#to_int when possible) would do,
    nikolai

    --
    Nikolai Weibull: now available free of charge at http://bitwi.se/!
    Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
    main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
     
    Nikolai Weibull, Aug 25, 2005
    #4
  5. Eric Mahurin

    Eric Mahurin Guest

    --- "David A. Black" <> wrote:

    > Hi --
    >=20
    > On Thu, 25 Aug 2005, Eric Mahurin wrote:
    >=20
    > > I was thinking how in seems a little asymmetric that many
    > > classes have #to_s method, but when you want to make one of
    > > those objects from a String, you have to clutter the String
    > > class with yet another #to_* method. So the String class

    > gets
    > > the burden of all those #to_* methods.

    >=20
    > I don't see that as a burden. It seems to correspond
    > precisely to
    > what's happening.
    >=20
    > > Instead, what if we
    > > would have the convention that creating an object from a

    > string
    > > would be a class method (for the class of that object)

    > instead
    > > of another String#to_* method. So, instead of these:
    > >
    > > String#to_i
    > > String#to_f
    > > String#to_sym
    > > String#to_<c> # where c is a abbreviation for the class
    > >
    > > you'd have these:
    > >
    > > Integer.from_s(str)
    > > Float.from_s(str)
    > > Symbol.from_s(str)
    > > klass.from_s(str)

    >=20
    > That seems like at least an equal amount of clutter --
    > actually more,
    > since you've now got a receiver, method, and argument, where
    > the
    > argument and the method name contain the same information
    > (String-hood
    > in this case). It also introduces a whole range of scenarios
    > involving wrong arguments. I prefer simply sending a
    > conversion
    > request to an object and getting its response.
    >=20
    > > Maybe you'd even want to be able to convert from an inspect
    > > string:
    > >
    > > klass.from_inspect(str)
    > >
    > > I'm not saying that we should replace all obj.to_ methods

    > with
    > > klass.from_ methods. I'm just saying to make them come in
    > > pairs. If you have a klass#to_* method, you should have a
    > > corresponding klass.from_* method if appropriate. This

    > would
    > > make your class more encapsulated, instead of having some

    > of it
    > > in String (or whatever class you are converting from).

    >=20
    > So you'd have:
    >=20
    > Integer.from_f(1.0)
    > Integer.from_s("1")
    > Integer.from_nil(nil)
    > Integer.from_i(1)
    >=20
    > instead of
    >=20
    > 1.0.to_i
    > "1".to_i
    > nil.to_i
    > 1.to_i
    >=20
    > I'm afraid it seems circuitous and verbose to me.



    Maybe for many of the core classes, there should be both forms
    if you are going from one core class to another.

    The ugliness I think is when you are dealing with an arbitrary
    class. You typically come up with an abbreviation for the
    class and make a String#to_<abbrev> method convert a string to
    an object of that class. You could have collisions with
    another class using the same name.

    The klass.from_s(str) form also offers a little more power. If
    you are dealing with an arbitrary class (possibly of another
    object) and you want to convert a String to an object of that
    class, you just call the from_s method of that class. You
    don't have to go figure out what the right String#to_* method
    to call is based on the class (and violate duck typing).

    You could also have klass#to_<coreAbbrev> and
    klass.from_<coreAbbrev>(coreOjbect) methods for other core
    classes or for that matter any known classes (i.e. yaml - y).



    =09
    ____________________________________________________
    Start your day with Yahoo! - make it your home page=20
    http://www.yahoo.com/r/hs=20
    =20
     
    Eric Mahurin, Aug 25, 2005
    #5
  6. Eric Mahurin wrote:

    > The ugliness I think is when you are dealing with an arbitrary
    > class. You typically come up with an abbreviation for the
    > class and make a String#to_<abbrev> method convert a string to
    > an object of that class. You could have collisions with
    > another class using the same name.


    Well, considering that there are only two methods in String by default:

    irb(main):003:0> String.methods.grep(/^to_/).sort
    => ["to_a", "to_s"],

    I really don't see the problem. How many classes need to be able to be
    created from a String anyway?,
    nikolai

    P.S.
    OK, the following is kind of ugly when you think about it:

    irb(main):004:0> require 'yaml'
    => true
    irb(main):005:0> String.methods.grep(/^to_/).sort
    => ["to_a", "to_s", "to_yaml", "to_yaml_properties", "to_yaml_type"]
    D.S.

    --
    Nikolai Weibull: now available free of charge at http://bitwi.se/!
    Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
    main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
     
    Nikolai Weibull, Aug 25, 2005
    #6
  7. On Aug 25, 2005, at 11:37 AM, Nikolai Weibull wrote:

    > Well, considering that there are only two methods in String by
    > default:
    >
    > irb(main):003:0> String.methods.grep(/^to_/).sort
    > => ["to_a", "to_s"]


    ??? ri shows me to_f, to_i, to_s, to_str, and to_sym.

    James Edward Gray II
     
    James Edward Gray II, Aug 25, 2005
    #7
  8. Eric Mahurin

    ts Guest

    >>>>> "J" == James Edward Gray <> writes:

    J> ??? ri shows me to_f, to_i, to_s, to_str, and to_sym.

    moulon% ruby -e 'p String.instance_methods(false).grep(/^to_/).sort'
    ["to_f", "to_i", "to_s", "to_str", "to_sym"]
    moulon%


    Guy Decoux
     
    ts, Aug 25, 2005
    #8
  9. James Edward Gray II wrote:

    > On Aug 25, 2005, at 11:37 AM, Nikolai Weibull wrote:
    >
    > > Well, considering that there are only two methods in String by
    > > default:
    > >
    > > irb(main):003:0> String.methods.grep(/^to_/).sort
    > > => ["to_a", "to_s"]

    >
    > ??? ri shows me to_f, to_i, to_s, to_str, and to_sym.


    Oops, I should have written String.new.methods....,
    nikolai

    --
    Nikolai Weibull: now available free of charge at http://bitwi.se/!
    Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
    main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
     
    Nikolai Weibull, Aug 26, 2005
    #9
    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. David
    Replies:
    2
    Views:
    480
    Thomas G. Marshall
    Aug 3, 2003
  2. Trevor

    sizeof(str) or sizeof(str) - 1 ?

    Trevor, Apr 3, 2004, in forum: C Programming
    Replies:
    9
    Views:
    642
    CBFalconer
    Apr 10, 2004
  3. John J. Lee
    Replies:
    12
    Views:
    485
    John J. Lee
    Jun 8, 2005
  4. Paganoni
    Replies:
    9
    Views:
    121
    Gregory Brown
    Apr 2, 2009
  5. Replies:
    0
    Views:
    183
Loading...

Share This Page