Why does String have to_str and Integer have to_int?

That's pretty much my question :slight_smile: Thanks.

···

--
Posted via http://www.ruby-forum.com/.

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

ditto for Integer.

···

On Mar 1, 2007, at 24:38, Nanostuff wrote:

That's pretty much my question :slight_smile: 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 :slight_smile:

···

On Thu, Mar 01, 2007 at 05:38:50PM +0900, Nanostuff wrote:

That's pretty much my question :slight_smile: Thanks.

Brian Candler wrote:

···

On Thu, Mar 01, 2007 at 05:38:50PM +0900, Nanostuff wrote:

That's pretty much my question :slight_smile: Thanks.

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?

--
Posted via http://www.ruby-forum.com/\.

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.

···

On Mar 1, 10:41 am, Brian Candler <B.Cand...@pobox.com> wrote:

On Thu, Mar 01, 2007 at 05:38:50PM +0900, Nanostuff wrote:
> That's pretty much my question :slight_smile: 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 :slight_smile:

Or

#to_s means an object *has a* String representation

and

#to_str means on object *is a* String representation

···

On Mar 1, 2007, at 06:45, tsela.cg@gmail.com wrote:

On Mar 1, 10:41 am, Brian Candler <B.Cand...@pobox.com> wrote:

On Thu, Mar 01, 2007 at 05:38:50PM +0900, Nanostuff wrote:

That's pretty much my question :slight_smile: 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 :slight_smile:

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 schrieb:

#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

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

···

On Mar 1, 8:49 pm, Eric Hodel <drbr...@segment7.net> wrote:

Or

#to_s means an object *has a* String representation

and

#to_str means on object *is a* String representation

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.

···

On 3/1/07, tsela.cg@gmail.com <tsela.cg@gmail.com> wrote:

On Mar 1, 8:49 pm, Eric Hodel <drbr...@segment7.net> wrote:
>
> 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

My blog on Ruby
http://talklikeaduck.denhaven2.com/

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

···

On Mar 1, 2007, at 4:23 PM, Rick DeNatale wrote:

Is Exception really a string representation?