(Hi I'm a new comer, just reading the first
lines of ruby code and I'm already dazzled)

> Ben Giddings wrote:
>
>> In Java you could check to see if something is of a certain class, but 
>> what was more often done was to see if something implemented a certain 
>> interface.  Implementing an interface was a way of signalling "I declare 
>> myself to act like a duck".  And the fact you implemented the interface 
>> meant that you had all the necessary features to act like a duck.  You 
>> weren't allowed to implement the interface and then only choose certain 
>> duck-like features.
>>
>> It seems to me that duck-typing in Ruby should strive for the same 
>> thing.  Checking for one method isn't enough, in my opinion.
>>
> I agree with Ryan's reply to you. If I only need the one method on the 
> object I'm interacting with -- should that one call not be allowed simply 
> because all of the other methods that I don't need aren't consistent with 
> what it *should* be?
>

I think that what Ben means isn't to replace this actual can_you_do_that?
way of thinking, but to extend it, just as there's nothing wrong with your 
argument:
"if all you need from the object is to execute this method, it doesn't 
matter what it is per se,
as long as it does it", the idea of implementing an interface comes 
naturaly as an extension.
(I don't program in java, so maybe what he talks about is actualy 
different, but that's how I understand it myself and how I wish to create 
my own object model).
it says "I declare that I act like a duck" that doesn't mean "I am a duck",
nothing prevents me from also being able to behave like an elephant or 
whatever,
even if in the end what i realy am is a completely different object.

while asking an obejct if he is able to execute a particular method is very 
useful,
the interface idea is much more powerful *and* useful.
first, the method_can_do? can lead to confusion, maybe I tell you
yes I can switch on, and yes I can switch off..
so, as a general object manager-scheduler, when I fall in your grasp
you say "this one I can 'pause' and run later.
However, I'm part of a lightning control system, and all I do is switch 
lights on and off.

the fact is, sooner or later, you'll have to consider that after all, even 
if my type isn't realy important,
the can_you_do_that? idea is just as misleading, when you want me to 
execute this method,
it's not because of the method itself, but because you want me to "behave a 
certain way"
(like a duck) I think it's better to ask me if I can behave like a duck and 
then ask me to quack,
then ask me if I can quack, and then make me do something totaly unrelated 
to the "duck quacking idea"
(maybe I start "quack arena" :)).

But of course, those confusions could be avoided by chosing wisely the 
method names (there *will*
however exist collisions, that's unavoidable) and, clearly, in the very 
same way, a duck interface
could be also confused, so the interface idea is not realy to prevent name 
collisions, but
to show that in the end what you want is a global behavior, not just a 
particular action..

 But the great advantage of a whole interface presentation would be for 
greater automated interactions
between objects, you could for instance, declare an object as being this- 
interface-friendly and by simply
asociating them, have them work automaticaly together. behind a well 
defined interface lie several methods
but also several "receptors" we'd know how to use.
I also hope ruby ducktyping goes in this direction, it would be of extreme 
usefulness, especialy in the case of distributed ruby where we should be 
able to make high level services interact intelligently with very few 
"duck-taping" code in between.


Olivier.