Duck typing

by Karel Thönissen

In comp.lang.eiffel Franck Arnaud noticed the following:

> The term was originally introduced by Dave Thomas, you can read his
> comments on it here: http://www.rubygarden.org/ruby?DuckTyping

I note he does not explain why he needed to invent a new name
for structural subtyping!

I think Frank has a point. Dave should at least have mentioned the word structural typing and explain the difference. However, there is a difference between structural type equivalence and duck type equivalence. Duck type equivalence of two instances means that both instances accept the same method invocations. Whether these two instances are based on the same or similar classes is irrelevant. Structurally, these two instances can be completely different. Classes are only used for the construction in that they help to give instances a start set of methods. New methods can be added and old methods can be removed at runtime. Due to this dynamism, the structures (classes) that were used for declaration are largely irrelevant. Duck typing does not permit static typing.

Structural equivalence defines two types to be equivalent if they are constructed from the same classes in the same way. Typically, languages using structural equivalence do not allow dynamic adding or removing of methods. Therefore, knowing the structure is enough to determine whether an instance can be used as a valid actual parameter for a given formal parameter position. Contrary to duck typing, structural equivalence can be determined at compile time and, thus, programs are as far as this is concerned, type-safe.

Just to make things a little more scientific I think that duck-type equivalence should be called interfacial type equivalence. So we get these sorts of type equivalence:

• nominal type equivalence (of two instances)
• objective type conformance (of two instances)
• structural type equivalence (of two types)
• interfacial type equivalence (of two instances)

The name objective type conformance is my own mint, but the concept is familiar from many object-oriented programming languages: two instances are conforming if their types are nominally equivalent, or if the type of one instance is a class that inherits from the class that is the type of the other instance. Notice that objective type conformance is not a symmetric relation, hence the name conformance rather than equivalence. Since the relation is asymmetric, we also need special rules for LHS-s and RHS-s and covariance and contravariance. That complexity is not needed for the nominal, structural and interfacial type equivalences since these are completely symmetric. Although objective conformance is the most complicated in the list, it is also the most attractive one for most applications: it combines the aggressive type checking of nominal typing with the flexibility of structural typing.

The Carmen programming language that we are developing is an object-oriented language that uses objective type conformance.