From: Alex Young <alex@...>
Date: 2006-07-24T20:58:53+09:00
Subject: Re: I'll have the duck!

Robert Dober wrote:
> On 7/24/06, Alex Young <alex@blackkettle.org> wrote:
<snip>
> The beauty of duck-typing is that you don't have to, though.
> 
> 
> Yes I agree 100% but the not-so-beauty is that I cannot (veryeasily)
> 
> If you wanted an Object#implements? method which doesn't rely on
> 
>> implementation via mixin, you could do it like this:
>>
>> class Object
>>    def implements?(module)
>>      my_methods = Set.new(self.public_methods)
>>      module_methods = Set.new(module.instance_methods)
>>      return my_methods.superset?(module_methods)
>>    end
>> end
> 
> yes I could, why not, nice idea
I think it does everything you're after.

> 
> Again, that misses the point somewhat, though - duck-typing lets you not
> 
>>   have to think about the concept of a defined interface (in the Module
>> sense, at least).  If your method only calls #foobar on a passed object,
>> then that object only need respond to the #foobar method.
> 
> Is this really a feature, all the times, I do  not think so.
Absolutely.  It's what makes the entire Enumerable module so useful. 
Every single Enumerable method works that way - the object only has to 
support the #each method for all of Enumerable's methods to be 
applicable.  The #to_s method is similar - anything that supports #to_s 
has a whole raft of functionality available to it because methods know 
that they've got a way of treating it as a string.

-- 
Alex