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. 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.

The term is a reference to the "duck test"—"If it walks like a duck and quacks like a duck, it must be a duck." One can also say that the duck typing method ducks the issue of typing variables.

Dave Thomas is thought to have originated the term in the Ruby community.

Comparison with generics and structural subtyping

---

In C++ and some other languages, very flexible static binding capabilities, called generics or templates or operator overloading, provided the same advantages, but typically not as late as run time. This static polymorphism was distinguished from runtime facilities for dynamic types, although most theorists considered this distinction to be undesirable.

The Smalltalk architects sought to achieve true polymorphism with the Smalltalk protocol proposal for abstract data types: static interfaces that existed only to guarantee a particular interface. Dynamic mechanisms used in these languages (such as genericizing the "method not found" exception handler into a catch-all lookup mechanism, parallels to which came to be called duck typing in Java and Python) would converge and employ a single reasonable syntax.

C++ templates implement a static form of Duck typing. An iterator, for example, does not inherit its methods from an Iterator base class.

Yet another approach similar to duck typing is OCaml's structural subtyping, where object types are compatible if their method signatures are compatible, regardless of their declared inheritance. This is all detected at compile time through OCaml's type inference system.

In Python

---

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.

In Java

---

In 2003, Dave Orme, leader of Eclipse's Visual Editor Project was looking for a generic way to bind any SWT control to any JavaBeans-style object, sometimes incorrectly known as a POJO, short for Plain Old Java Object. He noticed that SWT reuses names religiously across its class hierarchy. For example, to set the caption of something, you normally set the Text property. This is true for an SWT Shell (window), a Text control, a Label, and many more SWT controls. Orme realized that if he could implement data binding in terms of the methods that are implemented on a control, he would save considerable work and achieve a much higher level of code reuse, compared to implementing separate data binding for an SWT Shell, Text, Label, and so on. When the Ruby community started describing this kind of type system as "duck typing", Orme realized that he had simply rediscovered what Smalltalk, Ruby, Python and other programmers had already known for a long time.

Orme formalized this knowledge by creating a class that makes duck typing simple and natural for Java programmers (see "Java Does Duck Typing"). Cedric Beust later cautioned about possible dangers using duck typing in "The Perils of Duck Typing".

In ColdFusion

---

ColdFusion, a web application scripting language, also allows duck typing although the technique is still fairly new to the ColdFusion developer community. Function arguments can be specified to be of type any so that arbitrary objects can be passed in and then 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.

External links

---

• Duck Typing: Ruby
• Java Does Duck Typing. 2005-04-29. (a Java Implementation of duck typing)
• The Perils of Duck Typing (in Java)
• Python documentation
• Using tell() on a socket with GzipFile

Object-oriented programming | Type theory

Duck Typing