dblack / wobblini.net wrote:
> 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.

Is behavior not relevant to type?


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

   str = "foo"
   str.object_id         #=> 23456248224800
   str.to_str.object_id  #=> 23456248224800

> 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 don't think they have to be tied in with the classes, and I think we 
should try to avoid getting type mixed up with class. When I call #to_x, 
I expect to get an X type, meaning that I can call the methods defined 
by X on the object, and the object responds in an expected manner. I 
don't care if the object actually *is* an instance of X, just as long as 
is keeps its side of the deal and responds to the methods I throw at it.

I can see why some of the low-level methods might actually need an 
actual String or Numeric instance, but for high-level code I just don't 
see the point -- it's not like knowing the class means you can be any 
more sure that no-one has tampered with it.

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

Well, yes, an object's behavior *can* be modified on the fly. That's one 
of the selling points of Ruby. But by requiring that classes must 
inherit from some core classes, or that methods be defined on the core 
classes themselves, we restrict the flexibility of Ruby.


Daniel