From: Yukihiro Matsumoto <matz@...>
Date: 2011-01-12T10:18:55+09:00
Subject: [ruby-core:34397] Re: [Ruby 1.9-Feature#4264][Open] General type coercion protocol for Ruby

Hi,

In message "Re: [ruby-core:34366] Re: [Ruby 1.9-Feature#4264][Open] General type coercion protocol for Ruby"
    on Wed, 12 Jan 2011 02:14:24 +0900, Charles Oliver Nutter <headius@headius.com> writes:

|> (1a) Do we need a general solution for the to_a/to_s situation too?
|
|Maybe? The big problem with to_ary/to_str versus to_a/to_s is that
|there's no clear understanding of the differences.

I think I have explained before but I couldn't find the reference, I
will restate here.

 * 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.

 * 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.

							matz.