Why does String have to_str and Integer have to_int?

[Nanostuff]

That's pretty much my question Thanks.

 

[Eric Hodel]

That's pretty much my question Thanks.

A String is a String representation, so it converts to a String.

ditto for Integer.

 

[Brian Candler]

That's pretty much my question Thanks.

So you can write
a += b.to_i
or
puts c # which calls an implied #to_s

without getting an error if the argument already *is* an integer or a
string.

Now, as to why there are both #to_i and #to_int, and #to_s and #to_str, I
have no idea

 

[Peter Cho]

without getting an error if the argument already *is* an integer or a
string.

Ah, right. That's just about the only practical use for it then?

 

[tsela.cg]

So you can write
a += b.to_i
or
puts c # which calls an implied #to_s

without getting an error if the argument already *is* an integer or a
string.

Now, as to why there are both #to_i and #to_int, and #to_s and #to_str, I
have no idea

That's because those pairs of methods have different roles. The
difference is subtle, but important:
- #to_i and #to_s are conversion methods. They are used when one wants
a *representation* of an object as an integer or a string. Nothing
more, nothing less.
- #to_int and #to_str are duck-typing methods, basically. In other
words, they are methods that indicate that an object is Integer-like
or String-like. The difference is a semantic one rather than a
syntactic one. By supplying #to_str for instance, an object is
agreeing to be used when a string would normally be, and react like a
string in string contexts.

If you check the Core API on http://www.ruby-doc.org, you'll see for
instance that about a hundred classes implement #to_s, but only three
implement #to_str. That's because of their semantic difference: Float
can easily implement #to_s, since it's absolutely normal for numbers
to have a string representation. However, it doesn't implement
#to_str, because if it did it would basically be like saying that
Floats are like strings, which they are of course not. On the other
hand, Float implements both #to_i and #to_int because Floats can, as
fellow numbers, be used where Integers would be. They are Integer-like
enough.

Basically, look at #to_i and #to_s as giving representations, while
#to_int and #to_str are the sign that an object has a contract to
behave like an Integer or a String in corresponding contexts.

 

[Eric Hodel]

That's because those pairs of methods have different roles. The
difference is subtle, but important:
- #to_i and #to_s are conversion methods. They are used when one wants
a *representation* of an object as an integer or a string. Nothing
more, nothing less.
- #to_int and #to_str are duck-typing methods, basically. In other
words, they are methods that indicate that an object is Integer-like
or String-like. The difference is a semantic one rather than a
syntactic one. By supplying #to_str for instance, an object is
agreeing to be used when a string would normally be, and react like a
string in string contexts.

If you check the Core API on http://www.ruby-doc.org, you'll see for
instance that about a hundred classes implement #to_s, but only three
implement #to_str. That's because of their semantic difference: Float
can easily implement #to_s, since it's absolutely normal for numbers
to have a string representation. However, it doesn't implement
#to_str, because if it did it would basically be like saying that
Floats are like strings, which they are of course not. On the other
hand, Float implements both #to_i and #to_int because Floats can, as
fellow numbers, be used where Integers would be. They are Integer-like
enough.

Basically, look at #to_i and #to_s as giving representations, while
#to_int and #to_str are the sign that an object has a contract to
behave like an Integer or a String in corresponding contexts.

Or

#to_s means an object *has a* String representation

and

#to_str means on object *is a* String representation

 

[Wolfgang Nádasi-Donner]

#to_s means an object *has a* String representation
#to_str means on object *is a* String representation

Thanks for this very catchy description.

Wolfgang Nádasi-Donner

 

[tsela.cg]

Or

#to_s means an object *has a* String representation

and

#to_str means on object *is a* String representation

Great description! Thank you for summing up so well what I was trying
to say. I'm not good at catchy descriptions.

 

[Rick DeNatale]

Great description! Thank you for summing up so well what I was trying
to say. I'm not good at catchy descriptions.

Yes it's catchy, but

Is Exception really a string representation?


While the distinction here seems like it should be essential, it
appears to be somewhat accidental.

Some of these things seem to be to distinguish things which the
implementation wants rather than something inherent. It reminds me of
the discussion some time ago of the new to_splat method as another
analog of to_a and to_ary. I never thought that there was a consensus
as to which objects should implement to_splat.

I hope this doesn't seem too harsh, it's really intended as an
observation rather than a criticism.

 

[Gary Wright]

Is Exception really a string representation?

I think Matz and Co. agree with you...

$ irb
irb(main):001:0> Exception.new('message').to_str
=> "message"
irb(main):002:0>


$ irb1.9
irb(main):001:0> Exception.new('message').to_str
NoMethodError: undefined method `to_str' for #<Exception: message>
from (irb):3
from /usr/local/lib/ruby/1.9/irb.rb:150:in `block (2 levels)
in eval_input'
from /usr/local/lib/ruby/1.9/irb.rb:259:in `signal_status'
from /usr/local/lib/ruby/1.9/irb.rb:147:in `block in
eval_input'
from /usr/local/lib/ruby/1.9/irb.rb:146:in `eval_input'
from /usr/local/lib/ruby/1.9/irb.rb:70:in `block in start'
from /usr/local/lib/ruby/1.9/irb.rb:69:in `catch'
from /usr/local/lib/ruby/1.9/irb.rb:69:in `start'
from /usr/local/bin/irb1.9:13:in `<main>'



Gary Wright