idea: klass.from_s(str)

[Eric Mahurin]

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

 

[Nikolai Weibull]

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

 

[David A. Black]

Hi --

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

 

[Nikolai Weibull]

Nikolai Weibull wrote:

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

 

[Eric Mahurin]

Hi --
=20
On Thu, 25 Aug 2005, Eric Mahurin wrote:
=20
=20
I don't see that as a burden. It seems to correspond
precisely to
what's happening.
=20
=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
=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

 

[Nikolai Weibull]

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.

 

[James Edward Gray II]

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

 

[ts]

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

 

[Nikolai Weibull]

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