From Wikipedia, the free encyclopedia

In computer programming, duck typing is a style of dynamic typing in which an object's current set of methods and properties determines the valid semantics, rather than its inheritance from a particular class. The name of the concept refers to the duck test, attributed to James Whitcomb Riley, which may be phrased as follows:

If it walks like a duck and quacks like a duck, I would call it a duck.

In duck typing one is concerned with just those aspects of an object that are used, rather than with the type of the object itself. For example, in a non–duck typed language, one can create a function that takes an object of type Duck and calls that object's walk and quack methods. In a duck typed language, the equivalent function would take an object of any type and call that object's walk and quack methods. If the object does not have the methods that are called then the function signals a run-time error. It is this action of any object having the correct walk and quack methods being accepted by the function that evokes the quotation and hence the name of this form of typing.

Contents 1 Comparison with other type systems 1.1 Comparison with Structural type systems 1.2 Comparison with interfaces 1.3 Comparison with templates or 'universal' types 2 History 3 Implementations 3.1 In Python 3.2 In Ruby 3.3 In ColdFusion 3.4 In Smalltalk 3.5 In Objective-C 4 References 5 External links

Duck typing is similar to, but distinct from Structural typing, because in Structural typing schemes type compatibility and equivalence are determined by the type's structure; whereas in duck typing, type compatibility and equivalence are determined only by that part of a type's structure that is accessed. Examples include the language OCaml.

Interfaces can provide some of the benefits of duck typing but duck typing is distinct in that no explicit interface is defined. For example, if a third party Java library implements a class you are not allowed to modify, you cannot use an instance of the class in place of an interface you've defined yourself. Duck typing would allow this.

Template functions or methods apply the duck test in a static typing context; this brings all the advantages and disadvantages of static versus dynamic typing in general. Duck typing can also be more flexible in that only the methods actually called at run time need to be implemented, while templates require implementation of all methods that cannot be proven unreachable at compile time.

Examples include the language C++ with templates, Java generics, and various others.

Alex Martelli made an early (2000) use of the term in a message to the comp.lang.python newsgroup. He also highlighted misunderstanding of the literal duck test, which may indicate that the term was already in use.

In other words, don't check whether it IS-a duck: check whether it QUACKS-like-a duck, WALKS-like-a duck, etc, etc, depending on exactly what subset of duck-like behaviour you need to play your language-games with.

Duck typing is heavily used in Python. The Python Tutorial's Glossary defines duck typing as follows:

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 EAFP (Easier to Ask Forgiveness than Permission) programming.

The standard example of duck typing in Python is file-like classes. Classes can implement some or all of the methods of file and can be used where file would normally be used. For example, GzipFile implements a file-like object for accessing gzip-compressed data. cStringIO allows treating a Python string as a file. Sockets and files share many of the same methods as well. However, sockets lack the tell() method and cannot be used everywhere that GzipFile can be used. This shows the flexibility of duck typing: a file-like object can implement only methods it is able to, and consequently it can be only used in situations where it makes sense.

Duck typing is a fundamental part of Ruby coding. The "pickaxe book" (Programming Ruby), written by Dave Thomas and Andrew Hunt, has a more complete description of duck typing, explaining its perils and benefits.

The web application scripting language ColdFusion allows function arguments to be specified as having type any. For this sort of argument, an arbitrary object can be passed in and method calls are bound dynamically at runtime. If an object does not implement a called method, a runtime exception is thrown which can be caught and handled gracefully. An alternative argument type of WEB-INF.cftags.component restricts the passed argument to be a ColdFusion Component (CFC), which provides better error messages should a non-object be passed in.

The object-oriented programming language Smalltalk does not have type declarations for variables or method arguments and therefore naturally supports duck typing. Classes implementing the same protocol normally belong to the same inheritance hierarchy, but this is not required.

Objective-C, a cross between C and Smalltalk, allows one to declare objects of type 'id' and call any method on them, like Smalltalk. If the method is not defined on that object, an exception is raised. Thus, for method calls (or messages, as they are called in Objective-C), duck typing is fully supported by Objective-C.

• Duck Typing: Ruby
• How to duck type? - the psychology of static typing in Ruby
• Python documentation glossary entry on duck-typing
• Dr. Dobbs June 01 2005: "Templates and Duck Typing"
• Javascript 'typeof' limitations and duck typing