I'll have the duck!

ruby-talk
41

I don't think we disagree. I just said that's what I'd say -- not that
what you'd say is "wrong". Mine seemed a little more descriptive.

···

On Tue, Aug 08, 2006 at 09:08:40AM +0900, Jürgen Strobel wrote:

On Thu, Aug 03, 2006 at 12:39:38AM +0900, Chad Perrin wrote:
> On Thu, Aug 03, 2006 at 12:01:50AM +0900, Jürgen Strobel wrote:
> >
> > I repeat: duck typing is not to produce bombing out code, but a new*
> > way to handle dynamic and flexible type validation "late", with the
> > objective to ease development and produce clean code.
>
> I'd say that duck typing is more a means of allowing you to defer
> rigidity until it's actually beneficial. It has little or nothing to do
> with delaying validation, and everything to do with avoiding the
> unfortunate circumstance of having to validate before it's convenient
> for your code to have something to validate.

We seem to agree even if you think we don't.

"avoiding ... validation before it's convenient" vs. "delayed validation".

"defer rigidity" vs. "dynamic and flexible type validation"

Now where is the difference apart fom wording?

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky

42

Robert Dober wrote:
<snip>

The beauty of duck-typing is that you don't have to, though.

Yes I agree 100% but the not-so-beauty is that I cannot (veryeasily)

If you wanted an Object#implements? method which doesn't rely on

implementation via mixin, you could do it like this:

class Object
   def implements?(module)
     my_methods = Set.new(self.public_methods)
     module_methods = Set.new(module.instance_methods)
     return my_methods.superset?(module_methods)
   end
end

yes I could, why not, nice idea

I think it does everything you're after.

Again, that misses the point somewhat, though - duck-typing lets you not

  have to think about the concept of a defined interface (in the Module
sense, at least). If your method only calls #foobar on a passed object,
then that object only need respond to the #foobar method.

Is this really a feature, all the times, I do not think so.

Absolutely. It's what makes the entire Enumerable module so useful. Every single Enumerable method works that way - the object only has to support the #each method for all of Enumerable's methods to be applicable. The #to_s method is similar - anything that supports #to_s has a whole raft of functionality available to it because methods know that they've got a way of treating it as a string.

···

On 7/24/06, Alex Young <alex@blackkettle.org> wrote:

--
Alex

43

Hi --

> 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 :slight_smile:

Maybe we can fly. Maybe. But I do not believe so.
It just strikes me as if the community is throwing away so much by being,
forgive me to be blunt, intolerant about philosophies that are well known,
like early failing.
Although I said intolerant I want to add immediately that they are nicely
so, but quite firmely.

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.

I have to say sorry though about this one, I completely lost the original
topic in my holy war, good you pointed it out!
[Snip ]

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 :slight_smile:

David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
Ruby for Rails => 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

Cheers Robert

···

On 7/24/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

On Mon, 24 Jul 2006, Alex Young wrote:

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

44

Hi --

If it's a shift in paradigm, then it isn't "duck typing" (which is a
term invented to describe aspects of programming in Ruby).

Please choose a different animal :slight_smile:

The term "duck typing" predates Ruby, as I recall. I seem to remember
it being applied to Objective-C, for instance.

. . . not that anyone outside of NeXT used Objective-C for most of its
existence.

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.

David

···

On Tue, 25 Jul 2006, Chad Perrin wrote:

On Tue, Jul 25, 2006 at 05:48:29AM +0900, dblack@wobblini.net wrote:

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
Ruby for Rails => 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

45

Isn't that language called Io, like the natural satellite, and not IO,
like input and output? I ask because I'm not sure -- and I'm too lazy
to Google it right now.

···

On Thu, Aug 03, 2006 at 01:07:40AM +0900, Matt Todd wrote:

Also, on the other-languages discussion, IO is also a
prototype-based-OO language.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
This sig for rent: a Signify v1.14 production from http://www.debian.org/

46

Robert Dober wrote:
<snip>

Maybe we can fly. Maybe. But I do not believe so.
It just strikes me as if the community is throwing away so much by being,
forgive me to be blunt, intolerant about philosophies that are well known,
like early failing.
Although I said intolerant I want to add immediately that they are nicely
so, but quite firmely.

Duck typing doesn't stop you from failing early. If you combine the #implements? method with the monitor-functions example from earlier in the thread, you've got quite a nice interface checker.

You can have your duck and eat it too.

···

--
Alex

47

You may well be right. I'm afraid I'm not an expert in the etymology of
the term "duck typing". I'll take your word for it, for the time being.

···

On Tue, Jul 25, 2006 at 06:01:45AM +0900, dblack@wobblini.net wrote:

On Tue, 25 Jul 2006, Chad Perrin wrote:
>
>The term "duck typing" predates Ruby, as I recall. I seem to remember
>it being applied to Objective-C, for instance.
>
>. . . not that anyone outside of NeXT used Objective-C for most of its
>existence.

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.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
print substr("Just another Perl hacker", 0, -2);

48

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.

49

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

So your objection is merely semantic? If DuckTyping isn't the "proper"
word to use, what would you suggest? That little module I knocked
together was just a way to mix-in methods into any object that responds
to the proper quacks--er, messages. DuckTyping seems like a good way to
describe that to me.

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.

That sounds very silly, like saying that OOP or functional programming
can't be implemented in code.

Daniel

50

Nice 1.

···

On 7/24/06, Alex Young <alex@blackkettle.org> wrote:

Robert Dober wrote:
<snip>
> Maybe we can fly. Maybe. But I do not believe so.
> It just strikes me as if the community is throwing away so much by
being,
> forgive me to be blunt, intolerant about philosophies that are well
known,
> like early failing.
> Although I said intolerant I want to add immediately that they are
nicely
> so, but quite firmely.
Duck typing doesn't stop you from failing early. If you combine the
#implements? method with the monitor-functions example from earlier in
the thread, you've got quite a nice interface checker.

You can have your duck and eat it too.

--

Alex

Ah sorry I had the impression some are fairly opposed to that approach and
considered it unrubyfull. Maybe I am too *sensible*.

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

51

Hi --

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 :slight_smile: 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

···

On Tue, 25 Jul 2006, 7rans wrote:

dblack@wobblini.net wrote:

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
Ruby for Rails => 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

52

Daniel DeLorme wrote:

So your objection is merely semantic? If DuckTyping isn't the "proper"
word to use, what would you suggest? That little module I knocked
together was just a way to mix-in methods into any object that responds
to the proper quacks--er, messages. DuckTyping seems like a good way to
describe that to me.

  It's confusing. For my part, I wouldn't mind so much seeing a module
called 'DuckTyping'--I would think, 'Okay, here's someone taking a shot
at codifying a general concept'; but encountering the words 'duck' and
'quack' in actual method names makes me suspicious that someone is
trying to be "cute." Or the issue can be linguistic. To take the
example of your test module, on line 2 I see

  @@quacks = +whatever+

and my mind hits a rut. Is this a list of objects|methods|classes that
are capable of quacking, or of the different vocal sounds that ducks
make? Similarly, farther down you have a method called

  ducktype_method(methodname)

But is 'ducktype_method' a noun or a verb? Perhaps you can apperceive
the meaning of a method definition at first glance, but I (and probably
some others) have to think about it, and the reuse of the same minimal
vocabulary

  ducktype :quack do
    def quack_loudly
      quack.upcase
    end
  end

is frustrating. It would be even more so if I were brand-new to Ruby.

That sounds very silly, like saying that OOP or functional programming
can't be implemented in code.

  For this comparison to be valid, you would have to turn duck typing
into a programming paradigm: Duck-Oriented Programming. Is that really
worth it?

53

Hi --

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

So your objection is merely semantic? If DuckTyping isn't the "proper"
word to use, what would you suggest? That little module I knocked
together was just a way to mix-in methods into any object that responds
to the proper quacks--er, messages. DuckTyping seems like a good way to
describe that to me.

The problem is that "duck typing" is already "taken" :slight_smile:

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.

That sounds very silly, like saying that OOP or functional programming
can't be implemented in code.

I do wish we could keep "silly" and "delusional" and so on out of it.
Anyway -- my point is that duck typing is not a library-level language
facility that you or I can write and 'require' and thus add to Ruby. Even if there's a module called DuckTyping, people who ignore that module are still 100% as capable of using a duck-typing approach as people who use the module. The existence of the module is orthogonal
to both the duck-typing friendliness of the language, and the duck-typing programming style of the people using the language.

It's a bit like writing a module called ObjectOrientation. The module might do something wonderful, but it doesn't add object orientation to Ruby :slight_smile: (I think I stole that example from Chad Fowler, from a discussion of something else a couple of years ago.)

So my suggestion was, and is, to name your module something else, and
then trust duck-typing devotees (and others) to examine it and decide
whether it helps them out.

David

···

On Tue, 25 Jul 2006, Daniel DeLorme wrote:

dblack@wobblini.net wrote:

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
Ruby for Rails => 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

54

Hi --

···

On Mon, 24 Jul 2006, Robert Dober wrote:

On 7/24/06, Alex Young <alex@blackkettle.org> wrote:

Robert Dober wrote:
<snip>
> Maybe we can fly. Maybe. But I do not believe so.
> It just strikes me as if the community is throwing away so much by
being,
> forgive me to be blunt, intolerant about philosophies that are well
known,
> like early failing.
> Although I said intolerant I want to add immediately that they are
nicely
> so, but quite firmely.
Duck typing doesn't stop you from failing early. If you combine the
#implements? method with the monitor-functions example from earlier in
the thread, you've got quite a nice interface checker.

You can have your duck and eat it too.

Nice 1.

--

Alex

Ah sorry I had the impression some are fairly opposed to that approach and
considered it unrubyfull. Maybe I am too *sensible*.

I don't think I'd call interface-checking "duck typing", but if it
helps you build the program you want, then you should probably do it.

David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
Ruby for Rails => 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

55

dblack@wobblini.net wrote:

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.

Well, besides the fact that all code is the implementation of a way of
thinking, have you considered that you may be restricting the concept
arbitrarily? You say DuckTyping is like ElegantWay, and yet I was able
to use DuckType in psuedo-code in a meaningful way. I'd like to see you
do the same with ElegantWay. If what you say is true, how is that
possible?

Of course, you may argue that it's not meaningful, and that actually I
just have a delusional concept of duck typing that allows me to think
it's meaningful. Yet somehow everyone else in this discussion was able
to undestand me. Or are we all just delusional? Well, however you want
to slice up the semantic salad, the bottom line is I'm trying to *talk*
to people, and I'm going to use words that convey my meaning as
concisely as possible. "Duck" works fantasically well here --trying to
explain in another way, or coining another term would only make it more
difficult. Moreover, if I had, I imagine someone would have eventually
say, "isn't this just duck typing". After all, it's already been
erroneously called prototype-based OOP and AOP.

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 :slight_smile: 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).

Bull hockey (does this do a disservice to bulls or hockey? :wink:

The problem, David, is that you are adding _nothing constructive_ to
the conversation. You are merely being persnickety over terminology. No
one else is having any trouble over the use the word "duck" in the
code, or what it represents. Certainly I don't expect "duck" to become
a keyword of the language, but it serves perfectly well for this
exploration -- it is ultimately an analogy after all, "if it walks like
duck and talks like a duck..." We're using the analogy.

T.

56

Perhaps you should try being 'delusional,' for a change; doesn't your
customary lucidity become oppressive sometimes? Take a break. For
example, the next time someone levies that accusation, you say, 'Thank
you, madam; two lumps.'

        -J

57

dblack@wobblini.net wrote:

The problem is that "duck typing" is already "taken" :slight_smile:

*sigh*
And So, Faced With Insurmountable Semantic Opposition And A
Total Lack Of Suggestions, I Was Faced With The Lonely Task
Of Renaming My Proof-Of-Concept Module, Carefully Removing
Any Offending Reference To The Word "Duck":

module DependentMethods
   @@dependent_methods = Hash.new{ |h,k| h[k] = {} }

   def depending_on(*requisites, &block)
     o = self.is_a?(Class) ? self : self.class
     requisites.unshift(o)

     before = o.instance_methods
     o.class_eval(&block)
     after = o.instance_methods

     for methodname in (after - before)
       methodname = methodname.to_sym
       @@dependent_methods[methodname][requisites] = o.instance_method(methodname)
       o.send(:remove_method, methodname)
     end
   end

   def dependent_method(methodname)
     @@dependent_methods[methodname.to_sym].each do |requisites, m|
       if self.kind_of?(requisites[0])
         if requisites[1..-1].all?{ |r| self.respond_to?(r) }
           return m
         end
       end
     end
     return nil
   end

   def method_missing(methodname, *args, &block)
     if m = dependent_method(methodname)
       m.bind(self).call(*args, &block)
     else
       super
     end
   end
end
Object.module_eval{ include DependentMethods }

depending_on :quack do
   def quack_loudly
     ([quack.upcase]*(1+rand(3))).join
   end
end

class Anatidae
   def quack
     "quack!"
   end
end

d = Anatidae.new
puts d.quack_loudly #=> "QUACK!"

58

dblack@wobblini.net wrote:

Hi --

The problem is that "duck typing" is already "taken" :slight_smile:

>> 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.
>
> That sounds very silly, like saying that OOP or functional programming
> can't be implemented in code.

I do wish we could keep "silly" and "delusional" and so on out of it.
Anyway -- my point is that duck typing is not a library-level language
facility that you or I can write and 'require' and thus add to Ruby.
Even if there's a module called DuckTyping, people who ignore that
module are still 100% as capable of using a duck-typing approach as
people who use the module. The existence of the module is orthogonal
to both the duck-typing friendliness of the language, and the
duck-typing programming style of the people using the language.

It's a bit like writing a module called ObjectOrientation. The module
might do something wonderful, but it doesn't add object orientation to
Ruby :slight_smile: (I think I stole that example from Chad Fowler, from a
discussion of something else a couple of years ago.)

So my suggestion was, and is, to name your module something else, and
then trust duck-typing devotees (and others) to examine it and decide
whether it helps them out.

Er... Did someone put you in charge of the duck type club? I am a
duck-typing "devotee". But I am not a dogmatic lexicon beater. My use
of the term "duck" and "type" has a very clear sematic value to the
conversaion percisely because of the term Dave has "taken" --taken to
have a _useful_ meaning. But you want to insist that my use of the term
isn't "proper" and continue to waste our time on matters of "rosey"
triviality. Then let me oblige you in your own pursuit...

The term ducking typing, according to your own convictions can be
nothing of the sort. For it is completely contradictory to call
something a "type" when by defintion it excludes anything type
whatsoever. It would be more appropritate call it duck anti-typing, if
anything. Furthermore a duck is featuerd animal that tends to float
around in ponds all day and fly south for the wnter. I fail to see any
such creatures in your concept.

You see, the words "duck" and "type" were "taken" before you or Dave
hit the scene So I advise you to find another term. :slight_smile:

T.

···

On Tue, 25 Jul 2006, Daniel DeLorme wrote:
> dblack@wobblini.net wrote:

59

*nods* I tend to agree. When I posted earlier, it certainly seemed like the person I replied to had "gone beyond" or "gone elsewhere" from what I understand by the term "duck typing". As I said, it seemed a lot like prototype classes (adding capabilities to something based on the fact that it already has certain capabilities). I'd also agree that duck typing is a practice; you can do it with c++ templates, for instance, as far as I can see.

···

On 25 Jul 2006, at 05:06, dblack@wobblini.net wrote:

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 :slight_smile: 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).

60

Hmmm... David, my point is simply this: I understand your concern with
regards to the intended coinage of "duck typing" by Dave Thomas. But
this discussion is too protozoic to be overly concernd with exacting
nomenlature at this point. It is enough to _convey_ the idea intended.

T.