From: "T. Onoma" <transami@...>
Date: 2003-12-15T05:31:18+09:00
Subject: All there is to know about Duck Typing (was: inplace assignment)

On Sunday 14 December 2003 05:25 pm, David A. Black wrote:
> On Mon, 15 Dec 2003, T. Onoma wrote:
> > On Sunday 14 December 2003 03:59 pm, David A. Black wrote:
> > > I'm not sure what you mean by "duck similar" (the notion of duck
> > > typing doesn't scale well to "duck <this and that>"), but assuming you
> > > mean a class that defines methods with the same names and arities as
> > > another class, the best thing would probably be to do:
> >
> > See, you knew exactly what I was talking about, and I only used two
> > words! Seems to scale fairly well ;-)
>
> Two classes being described as "duck similar" brings the whole thing
> back to a tight bonding between class and type.  At the very least,
> someone who was new to the notion of duck typing, or encountered it
> subsequent to having been told that two Class objects exhibited "duck
> similar[ity]" precisely because they defined similar interface (which
> is exactly what duck typing does *not* reflect), would, I expect, find
> it that much harder to grasp that the point of "duck typing" is that
> it offers an alternative to class-based ways of thinking about type.

Certainly you have a point, my only quibble with what you are saying is 
exactly that. This is really a quibble. I was trying to convey the idea of a 
replacement class having the responding methods required of the needed 
context similiar to the pre-existent class it replaces, but it in no way 
entails that they will have all or even nearly all the same methods. I tried 
to convey this concisely by my phrase, which you appeared to understand quite 
well, enough at least that you were comfortable in telling me it was a poor 
choice of words. But this only affirms my intention which was to communicate 
an idea, not make a definition. Morevoer, if I were to only have said 
"similiar" you may have still understood me, but there would have been a 
greater chance for one to ask "similiar in what way?".

> This doesn't mean that two classes can't have similarly named
> methods; it just means that there's nothing 'duck'-related about it.
> If anything, the relation of duck typing to class objects would have
> to do with their dynamic profiles, particularly as regards singleton
> (class) methods.

The later is certainly true. As to the former, if there is no relavence to 
classes sharing *exactly* the same method names, then how can Duck Typing 
even be possible? There is undoubtedly a relationship.

Actually maybe that is the source of this confusion. To me Duck Typing has two 
related sides on the same coin. One is as you mention, dynamic addition (or 
removal) of methods from objects. Hence "Duck Type" != Class. But secondly, 
there is also the object substituion that can take place: Polymorphism, which 
I believe is essenstialy what Duck Typing is about. Take this definition on 
the second link I came up with in a google search:

  Polymorphism is ability of objects to act depending of their run-time type.
  (see: http://bepp.8m.com/english/oop/polymorphism.htm)

I think that's the bottom line really: *run-time type*.  That's duck typing. 
Dave just came up with a fun new name; a name I happen to really like.

T.