From: Charles Oliver Nutter <headius@...>
Date: 2011-01-12T14:09:47+09:00
Subject: [ruby-core:34404] Re: [Ruby 1.9-Feature#4264][Open] General type coercion protocol for Ruby

On Tue, Jan 11, 2011 at 7:18 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> ��* to_s, to_i, to_f, to_a etc. are conversion method. ��For example, if
> �� a object can be converted into a string, it would have to_s method,
> �� but it doesn't have to behave like a string.
>
> ��* to_str, to_int, to_ary are implicit conversion method. ��Some
> �� objects mimic built-in objects do not have same internal
> �� structures, but C defined methods requires the structure, so to_str
> �� and the likes work as hooks to retrieve C structure like RString.
> �� The object that provide to_str should behave as a string.

I guess I'm confused what the difference is. For example, sometimes
to_ary is used as a marker, and not invoked. Sometimes it is invoked
and expected to return an array. There are many cases in RubySpec
showing both behaviors. So it seems to be a more narrow conversion
method, but it still seems like a conversion method to me.

> ��* String() and Array() are conversion methods, so (in case of String)
> �� it first try to_str to check if they are string, then try to_s to
> �� get string object.
>
> If there's any usage of to_x methods that does not fit above
> principles, I consider it as a bug.
>
> I think we are discussing general conversion way to replace to_s,
> etc. here, not to_str and alike.

Based on your above description, I agree.

Can you provide more clarification:

* Are to_ary/to_str/to_int intended only for use from core methods?
* Are they expected to always return the an instance of the appropriate type?
* Should users be defining these methods to produce new structures in
the same way as they define to_a, or should they only be doing so if
their class can duck-type as an array/string/integer for all
array/string/integer methods?

- Charlie