Hi --

On Tue, 25 Jul 2006, 7rans wrote:

>
> 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.

No misstatement: Duck typing isn't something one can implement in
code.  If you say, "So-and-so codes in an elegant way", that doesn't
mean that the next step is to create an ElegantWay module.  Duck
typing, as Dave Thomas has put it, is a way of thinking about
programming in Ruby.  You may write a module that people who think
that way find useful, but that doesn't mean that it should be called
DuckTyping.  You cannot implement a way of thinking, per se, in code.

> 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.

I seem to have hit some kind of nerve here.  (To parapharse your
earlier comment: I'll take your characterization of me as "delusional"
as a misstatement :-)  But reread what I wrote originally.  It's got
nothing to do with stymying innovation.  I'm just suggesting that
hitching all of this experimentation to the "duck/quack" wagon, when
it comes to method and class and module names, does a disservice to
both the duck typing concept (which isn't about writing modules called
Duck) and to the code you're writing (the possible usefulness of which
is obscured by the peculiar names).


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