Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > idea: klass.from_s(str)

Reply
Thread Tools

idea: klass.from_s(str)

 
 
Eric Mahurin
Guest
Posts: n/a
 
      08-25-2005
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


 
Reply With Quote
 
 
 
 
Nikolai Weibull
Guest
Posts: n/a
 
      08-25-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. 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);}


 
Reply With Quote
 
 
 
 
David A. Black
Guest
Posts: n/a
 
      08-25-2005
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
http://www.velocityreviews.com/forums/(E-Mail Removed)


 
Reply With Quote
 
Nikolai Weibull
Guest
Posts: n/a
 
      08-25-2005
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);}


 
Reply With Quote
 
Eric Mahurin
Guest
Posts: n/a
 
      08-25-2005


--- "David A. Black" <(E-Mail Removed)> 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


 
Reply With Quote
 
Nikolai Weibull
Guest
Posts: n/a
 
      08-25-2005
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);}


 
Reply With Quote
 
James Edward Gray II
Guest
Posts: n/a
 
      08-25-2005
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


 
Reply With Quote
 
ts
Guest
Posts: n/a
 
      08-25-2005
>>>>> "J" == James Edward Gray <(E-Mail Removed)> 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


 
Reply With Quote
 
Nikolai Weibull
Guest
Posts: n/a
 
      08-25-2005
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);}


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments