From: dblack@...
Date: 2006-05-29T15:02:21+09:00
Subject: Re: Crazy thought -- Rubyish type conversion?

Hi --

On Mon, 29 May 2006, Daniel Schierbeck wrote:

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

I think I'm not understanding what you mean by the context of an
object.  Your example involves two different objects (I assume), so
I'm not clear on which object's context/type you're referring to.  Or
do you mean the context in which a given method name appears?

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

Well, at least it's not 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 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.

What I mean is: there's already a convention of using to_* for these
class-specific conversion methods, so if you want to create a system
of true type (as opposed to class) conversions, to_* might be a
misleading name.

In other words, I'm not suggesting that how the core to_* methods work
should be a model for how everything should work, but only that
anything that doesn't work the way they work maybe shouldn't be called
to_*.


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