Devin M. wrote:
For backwards compatibility with the great majority, “duck typing” will
mean “just calling methods on an object, without doing any validation on
the behavior of that object.”*
The great majority of whom? If you mean rubyists, perhaps you’re right
(though I don’t know). If you mean programmers, language designers and
computer scientists in general, I think you’re wrong.
“Duck typing” is not something that you do, and is not even how you
do something; it is a method of relating objects – a sort of “type
system” (“type” in the generic sense not the C-type sense; i.e., “A
type indicates a set of values that have the same sort of generic
meaning or intended purpose (although some types, such as abstract
types and function types, might not get represented as values in the
running computer program).” [1]).
In the terms of category theory: "Instead of focusing merely on the
individual objects (groups) possessing a given structure […] category
theory emphasizes the morphisms - the structure-preserving processes
- between these objects. […] A category is itself a type of
mathematical structure, so we can look for ‘processes’ which preserve
this structure in some sense. Such a process is called a functor. It
associates to every object of one category an object of another
category; and to every morphism in the first category a morphism in the
second." [2]
So “In computer science, duck typing is a term for dynamic typing
typical of some programming languages, such as Smalltalk or Visual
FoxPro, where a variable’s value itself determines what the variable
can do. Thus an object having all the methods described in an interface
can be made to implement that interface dynamically at runtime, even if
the object’s class does not include the interface in its implements
clause. It also implies that an object is interchangeable with any
other object that implements the same interface, regardless of whether
the objects have a related inheritance hierarchy.” [3]
The python glossary defines the expression similarly: “Pythonic
programming style that determines an object’s type by inspection of its
method or attribute signature rather than by explicit relationship to
some type object (“If it looks like a duck and quacks like a duck, it
must be a duck.”) By emphasizing interfaces rather than specific types,
well-designed code improves its flexibility by allowing polymorphic
substitution. Duck-typing avoids tests using type() or isinstance().
Instead, it typically employs hasattr() tests or [Easier to ask for
forgiveness than permission] programming” [4] Note also that python
calls the method of programming which you call “duck typing” – “just
calling methods on an object, without doing any validation on the
behavior of that object” – “Easier to ask for forgiveness than
permission”
Structural type systems, as found in dialects of ML and other
languages, are very similar to duck typing. “In structural typing, two
objects or terms are considered to have compatible types if the types
have identical structure.” [5] This “structure” is often referred to as
the “shape” or “signature” of the object / type.
Now I don’t know if Dave T. used the expression “duck typing”
differently than others generally do, leading to it having a different
nuance in the ruby community; or if perhaps the community didn’t
understand Mr. Thomas; or some combination of the two (or, as a third
alternative, the community doesn’t generally have that notion of “duck
typing”). But generally speaking “duck typing” does not require or even
imply any specific programming approach (including the approach where
one simply expects / trusts that one object will act like / has the
same (or pragmatically similar) signature as another). If it did, then
(in many cases) when you write begin…rescue, you’d be violating “duck
typing”, because you’re no longer trusting the object, but are imposing
a condition on it – you’re just doing it “after the fact”, so to
speak: try it → failed → do something else. This is no different in
concept from ask about it → failed → do something else, it’s just a
different implementation.
So, in colloquial terms, I see no reason why “ask if it walks like a
duck before you believe its a duck” should be a violation of “duck
typing” any more than “expect it to walk like a duck but don’t believe
its a duck if it doesn’t”.
Ps. I also agree with Matz. I see no reason for zealotry. If I’m wrong,
that’s OK; I’ve been wrong plenty of times before and will be wrong
again. No need to get upset over it.
[1] Type system - Wikipedia
[2] Category theory - Wikipedia
[3] Duck typing - Wikipedia
[4] http://docs.python.org/tut/node18.html#l2h-46
[5] Structural type system - Wikipedia
Regards,
Jordan
