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

On Tue, Jan 11, 2011 at 10:27 AM, Jim Weirich <jim.weirich@gmail.com> wrote:
> (1) This is a extending the concept of to_ary and to_str to arbitrary
> classes, (as opposed to extending the concepts of to_a and to_s). ��Correct?

Correct.

> (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. Up through 1.8.7,
to_a was defined on all objects, with the default behavior just
returning a one-element array of that object. to_s is still defined on
all objects. On the contrary, to_ary and to_str are specifically
implemented only on objects that have a "natural" conversion to those
types.

I guess I see the difference being that to_ary/to_str are like
slightly softer type-casting operations and to_a/to_s are hard,
unconditional conversions. What would the equivalent be for "to"?

> (2) Will there be a way of specifying the conversion in both directions?
> ��For example, if I add my own container type (JimContainer), will I be able
> to specify the coercions Array->JimContainer and JimContainer->Array?

I added to the bug a proposal for double-dispatch; I think that would
address it neatly:

class JimContainer
  def to(type)
    case type
    when Array
      (your array conversion logic)
    ...
end

and Array would simply dispatch to JimContainer.coerce(ary).

- Charlie