[ruby-core:34376] Re: [Ruby 1.9-Feature#4264] General type coercion protocol for Ruby

On Jan 11, 2011, at 12:09 PM, Charles Nutter wrote:

> Issue #4264 has been updated by Charles Nutter.
>
> Other thoughts after talking with tenderlove:
>
> 1. double-dispatched protocol
>
> The #to protocol could double-dispatch against the class, as in:
>
> def to(type)
>  type.coerce(self)
> end
>
> This would allow defining coercions on the target class, rather than  
> on the #to method. It does incur the hit of doing a double-dispatch  
> though.

I like the double dispatch idea.  However I have a couple comments on  
the above.

First, a minor nit:  "coerce" is already used in Ruby (for resolving  
types in operator expressions).  I'm not sure if the above code would  
interfer with the current usage or not.

A more subtle issue is this.  At the end of double dispatch you should  
know the concrete types of both source and destination classes.  The  
above code is fine for double dispatching in statically typed  
languages because coerce would be static selected from a list of  
overloaded coerce functions matching the type signature.

Unfortunately in Ruby, once you dispatch on coerce (the 2nd dispatch,  
the first dispatch is on "to"), you still don't know the concrete type  
of the argument to coerce.  Coerce would have to still do some kind of  
lookup based on the type of self.  If we still got have to do a lookup  
after the second dispatch, then we might as well get rid of the second  
dispatch and just do the lookup in the "to" method.

To stay with double dispatch in a dynamic language like ruby you need  
to encode the type name into the method.  For example, adding "to" to  
SourceClass would look like:

   class SourceClass
     def to(type)
       type.coerce_from_SourceClass(self)
     end
   end

Coercion in the target class would look like this:

   class TargetClass
     def self.coerce_from_SourceClass(source_object)
       # In this code we know the concrete types
       # of both self and source_object.  No need
       # for any further lookup.
     end
   end

A couple points:

(1) coerce_from_xxx avoids semantic conflicts with the current use of  
coerce.

(2) We need a scheme for handling classes nested in modules.  (e.g.  
coerce_to_Module::Class isn't going to fly).

(3) This scheme is completely extensible for both new source types and  
new target types.  It does require monkey patching target classes with  
a new coerce_from_xxx method, but the class name is part of the method  
name, so there is no chance for name collision.

(4) You could easily write a generic "to" method in Object that would  
look like:

    class Object
      def to(type)
        type.send("coerce_from_#{type}", self)
      end
    end

That involves the overhead of a send and string conversion, so there  
are some convenience VS efficiency tradeoffs to consider.

(5) I think the symbolic coercion you mentioned could be worked into  
this, but I haven't thought through the details yet.

-- 
-- Jim Weirich
-- [e-mail]