dblack / wobblini.net wrote:

> I've always thought that Dave Thomas coined it, and that it then
> caught on (including outside of Ruby).  Either way -- I think that
> using "duck" in method and class names dilutes the meaning of "duck
> typing", and also does a disservice to the stuff people are writing,
> some of which may be quite interesting.  When I see these
> prototype-style libraries named "duck" this and that, I'm just aware
> of the fact that duck typing isn't something one can implement in
> code, and that therefore the point of this code is being obscured
> rather than revealed by the naming.

This argument has been made before, notably by you, and it simply does
not hold-up to scrutiny. First of all, how can a programming language
do anything that does not arise from implementation. That's completely
contradictory. But I'll take that to be a misstatement, and you
actually just mean that duck-typing is not something you explicitly
declare, but rather is an implicit occurance of not imposing type
restrictions on method arguments. However you are wrong to think that
there is no imposition being made at all. When an object is the
receiver of a message to which it does not respond, it readily object
with a resulting NoMethodError. So disavowing #respond_to? as
antithetical to duck-typing is simply delusional. Explicit is just the
otherside of the implicit coin.  Defining a set of methods based on a
conformity to a "duck type" is therefore not contrary to the original
coinage, but in reality furthers it by taking into account all side.
Which is what I was saying with my original post, that the "duck"
concept as currently implemented may yet be only half turned. It would
then be clear that your hold to this specific idea of the
inexpressibility of a duck type is effective only at stymieing
innovation in the area.

T.