From: "David A. Black" <dblack@...>
Date: 2005-01-14T22:29:53+09:00
Subject: Re: Duck Typing and automated Conversions

Hi --

On Fri, 14 Jan 2005, Robert Klemme wrote:

>> [I wrote:]
>>
>> There's also the question of the interaction of this with duck typing.
>> Of course that's always a programmer's choice, but I could imagine
>> cases where the caller would expect a duck-typing treatment and not
>> get it.  For example:
>>
>>    obj = Object.new
>>    def obj.times; 10; end
>>    str = silly_example("hello", obj)
>>
[...]
> Btw, did you purposely just return an int from your definition of times?
> I mean, no block is invoked from that method.

I did it wrong.  It should be:

   def obj.times(&block)
     10.times &block
   end

>> (Of course you could document your method by saying that it requires
>> an object that responds to to_int, but that seems a bit roundabout
>> compared to just saying you want an object that responds to times.)
>
> It's just another (supposedly shorter) form to write a common idiom.  If
> the writer of silly_example decides to do more complex treatment, he can
> still do that.  We don't loose anything.  Note, that the creator of your
> obj.times() would be similarly surprised if the implementor of
> silly_example had choosen to do it exactly like I presented in the first
> example.
>
> I'm not sure whether I missed your point altogether.  Could you please
> elaborate?  Thanks!

Partly I'm just very conservative about special-case syntax and
shortcuts.  I can't define exactly why, or exactly where I draw the
line, or whether there's even a line....  I think I'm also not
convinced that this (to_int etc.) is common enough or special enough
to warrant a change in method definitions semantics.  I don't think I
can get much more concrete than that, so it may be that at some level
I don't have a point, rather than that you've missed it :-)


David

-- 
David A. Black
dblack@wobblini.net