[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Why does String have to_str and Integer have to_int?

NanoStuff

3/1/2007 8:39:00 AM

That's pretty much my question :) Thanks.

--
Posted via http://www.ruby-....
9 Answers

Eric Hodel

3/1/2007 8:59:00 AM

0

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

> That's pretty much my question :) Thanks.

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

ditto for Integer.

Brian Candler

3/1/2007 9:42:00 AM

0

On Thu, Mar 01, 2007 at 05:38:50PM +0900, Nanostuff wrote:
> 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 :-)

NanoStuff

3/1/2007 12:50:00 PM

0

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

tsela.cg

3/1/2007 2:42:00 PM

0

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

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.ru..., 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

3/1/2007 7:49:00 PM

0

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 :) 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 :-)
>
> 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.ru..., 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

WoNáDo

3/1/2007 8:25:00 PM

0

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

tsela.cg

3/1/2007 9:02:00 PM

0

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

3/1/2007 9:23:00 PM

0

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.

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.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Gary Wright

3/1/2007 9:45:00 PM

0


On Mar 1, 2007, at 4:23 PM, Rick DeNatale wrote:
> 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