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