From: ara.t.howard@...
Date: 2006-07-27T00:26:31+09:00
Subject: Re: I'll have the duck!

On Wed, 26 Jul 2006 dblack@wobblini.net wrote:

>> would be D. Conway's name for the general consequence of building
>> projects with this kind of model in mind.
>
> Don't forget, though, that duck typing was originally intended as a
> description of something that a programmer does.  I've also always tended to
> see it as a property of the language (i.e., Ruby as a "duck-typed" language,
> as Jim Weirich has said) -- since the method-call is always isolated from
> any ancestry checks and so forth that surround it -- but, as I understand
> Dave's take on it, it does refer at least equally to a programming
> attitude/style/philosophy (or whatever the best term is).

hmmm.  see, i don't think these two ideas are at odds because i agree with you
that 'duck typing' can't be implimented via a module (recall that it's this
conecpt the started the thread long, long, long ago!).  what was bothering me
about that is the lack of a concrete term that can actually describe real ruby
objects in real ruby code.  to say that they a specific object is 'interface
polymorphic' is a way of saying what tom was getting at - that the object will
respond_to some set of methods (potentially via method_missing) - and is,
therefore, an acceptable argument to some method while avoiding the nasty
'is_a' typing issue.

also, on further consideration, i'm thinking that duck typing is indeed more
of a concept and less a hard and fast set of coding constructs.  consider

   def m
     yield :foobar
   end

i'd say this is equal in spirit to

   def m obj
     obj.foobar
   end

in the first case we simply do not check whether a block was given or, if it
was, if it accepts at least one argument.  note that this example does not
involve an object whose interface may be checked.  nonetheless i think it's in
the spirit of 'duck typing' to say that this method is 'duck typed' (bad term
in know) because we are asserting any preconditions on how it's called and
accept that unit-testing and runtime failures are our only tools to track down
errors in calling it.

contrast that to the second case where an actual object is passed to 'm' and
it's required to respond_to? the message 'foobar'.  in this case we are also
thinking in 'duck terms' but we can also say that 'obj' is required to be
'interface polymorphic' to the set of objects that respond_to 'foobar' called
with no arguments.  this __is__ something that can be verified (ignoring race
conditions inherent in dynamic languages with methods being added) and,
therfore, encapsulated in some sort of module.

in summary i'm suggesting 'interface polymorphism', or some cute short-hand
like PolyFace, as terminology for an implimentation which encapsulates the
process of ensuring/checking an object's method signatures/behaviours to
determine if that object is allowed to pass a gate or not.

regards.

-a
-- 
suffering increases your inner strength.  also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama