From: dblack@...
Date: 2006-07-24T21:03:16+09:00
Subject: Re: I'll have the duck!

Hi --

On Mon, 24 Jul 2006, Alex Young wrote:

> If you're always supplying Duck's functionality as a mixin, you can do:
>
> Duck === d
> => true
>
> The beauty of duck-typing is that you don't have to, though.

I'd go further: the definition of duck typing is that you don't :-)

I think Dave Thomas was always pretty explicit about saying that duck
typing, in practice as well as theory, is something one does *instead*
of checking class/module ancestry.  I think the use of Duck, duck,
quack, etc. as class and method names is kind of misleading.  It moves
the class-checking approach into the "duck" namespace -- which means
that "duck typing" gets redefined, and it also means that the thing
originally called "duck typing" is left without a name.

What it always comes down to for me is this: in Ruby, at the moment
that you send a message to an object, you send a message to an object.
No amount of checking of class membership -- not even, technically,
the prior checking of respond_to? -- has any bearing on what happens
when that message is sent.

Duck typing is Dave's name for an approach to Ruby programming that
attempts to live in harmony with this underlying state of things in
Ruby, rather than covering it up or pretending it isn't there.

There are two major ramifications of duck typing:

   1. it leads you to understand what's actually happening every
      time you call a method in Ruby;
   2. it points the way to interesting and productive things you
      can do to harness the way Ruby works, rather than fighting it.

I've always agreed with Jim Weirich that Ruby is "a duck-typed
language".  In other words, as far as Ruby is concerned, everyone is
duck typing: everyone is sending messages to objects, and those
message-sending events are never connected directly to an object's
ancestry.  Hence #1 in the list above.

As for #2 -- it's not that it's a mark of shame to use #is_a? and
#respond_to?, but rather that Ruby does provide a programming
environment in which it's possible, thanks to a design that eschews
certain constraints, to do otherwise, with good results.

Final note to Alex: much of what's here is in response to the whole
thread, even though it's in a response to your post :-)


David

-- 
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black     => RUBY FOR RAILS (reviewed on
                                     Slashdot, 7/12/2006!)
http://dablog.rubypal.com        => D[avid ]A[. ]B[lack's][ Web]log
dblack@wobblini.net              => me