From: MonkeeSage Date: 2006-09-21T13:45:12+09:00 Subject: Re: Ducktator - A Duck Type Validator Devin Mullins 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 Thomas 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] http://en.wikipedia.org/wiki/Type_system [2] http://en.wikipedia.org/wiki/Category_theory [3] http://en.wikipedia.org/wiki/Duck_typing [4] http://docs.python.org/tut/node18.html#l2h-46 [5] http://en.wikipedia.org/wiki/Structural_type_system Regards, Jordan