Hi --

On Sun, 28 May 2006, Daniel Schierbeck wrote:

> dblack / wobblini.net wrote:
>> It sounds like you're talking about class, rather than type, or
>> (since, as you say, to_x doesn't actually have to return an X) just a
>> kind of convenience method-call layer.  I'd rather see the methods
>> spelled out.
>
> No, I don't mean class -- I think of "type" as the context of an object, one 
> that cannot always be deducted by it's methods:
>
>  phone.call
>  method.call
>
> these two #call methods are in different contexts -- I think of the #to_* 
> methods as a way to determine that context.

But that's a different matter from either the class or the type of
phone and/or method.

> If I call #to_a on an object, I 
> expect the result to be an array -- I could've just called #[] and what not 
> on the original object, but that would require that the object only used #[] 
> the same way an array does. By using the #to_* methods, objects can be in 
> several different contexts. At least that's how I see it.

Don't forget, though, the "to" in to_* really means a *different*
object.  It's not the same object behaving differently.

The built-in to_* methods are very class-specific, and in a sense are
not the best advertising for duck typing, though they are very
convenient and they're closely tied in with the most basic built-in
classes.  I think I'd expect any method named to_* to fit into that
pattern.  In a sense, it sounds like you're describing modular
extension:

   obj.extend(SomeModule).some_method

or something like that, where an object's behaviors can be modified on
the fly.


David

-- 
David A. Black (dblack / wobblini.net)
* Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
   > Ruby and Rails consultancy and training
* Author of "Ruby for Rails" from Manning Publications!
   > http://www.manning.com/black