In object-oriented programming, duck typing means orienting on what interface an object exposes rather than on what its class is.
If it walks like a duck, and quacks like a duck, it's a duck. With duck typing one does not specify what type of object an argument to a routine should be. Rather, one specifies what methods it must support, and what those methods do. Any object, regardless of type, can be passed to the routine if it provides the required methods. Traditionally, a statically-compiled object-oriented language is not conducive to duck typing because at compile time the compiler must know the type of the object. Java works around this constraint and provide duck typing via the concept of interfaces.
Tcl is an odd duck. An argument to a routine does not provide any methods because it is not an object. In Tcl there are no objects. There are only values. In languages like Python, there are no values. There are only objects that can be used as values.
Duck typing is yet another case where a term simply doesn't apply to Tcl, at least not in its commonly-understood sense. Tcl simplifies the criteria: If it looks like a duck, it's a duck.
AMG: In Tcl, each value's data type is implicitly determined by the operations performed on the value. This is called "duck typing" [L1 ].
set data {1 2 3 4} ;# $data is a string
llength $data ;# $data is a list
dict size $data ;# $data is a dict
set data 42 ;# $data is a string
expr $data ;# $data is an expression (beware of side-effects through nested commands)
expr {$data} ;# $data is an integer
regexp $data 4242 ;# $data is a regexp
set data expr 99 ;# $data is an integer
string length $data ;# $data is a stringand so on.
Beware of shimmering!
AMG (conversation moved from Wikipedia, 2014-05-28): Tcl pretty much wrote the book on duck typing.
PYK 2014-05-28: I sorta thought Python wrote the book on duck typing. I think expanding the presence of Tcl on Wikipedia is a very useful activity, and hope someone finds the time to expand the duck typing article there.
MSH 2015-11-27: It appears there are no references to TCL at all on the "duck typing" [L2 ] page. AMG: That is a shame. But when I said the conversation was moved from Wikipedia, I meant it was moved from the Tcl Wiki page on Wikipedia, not from the Wikipedia page on Duck Typing.
AMG: Not at all. In Python, types are intrinsic in values, whereas in Tcl, types exist only within the program's interpretation of values.
Python sees "2", 2, and (2,) as distinct, and they cannot be +'ed (added or string/list concatenated) without the programmer explicitly begging that one be converted from str to int, or vice versa, plus don't forget about unpacking single-element tuples or lists.
Tcl sees no distinction between the three, though it renders the single-element tuple (2,) as simply 2. The determination between adding or string/list concatenation is made not by the inherent type (a concept foreign to Tcl), but rather by having adding and string/list concatenation being separate operations.
With Tcl, the type is inferred according to the operations being performed on the value, and the type can freely change from moment to moment with no need for explicit conversions. The interpreter figures out the type based on what the programmer is trying to do.
set operands {"2" 2 {2}}
tcl::mathop::+ {*}$operands ;# 6
join $operands {} ;# 222
list {*}$operands ;# 2 2 2With Python, the type is explicitly declared according to how the value was constructed. Surround it in quotes, and it's a string. Put it in brackets, and it's a mutable list. Put it in parentheses with commas, and it's an immutable tuple. Put it in braces, and it's a dict. And so forth. Conversions are not automatic, and the programmer has to explicitly ask for them.
operands = ("2", 2, (2,))
def collapse(x):
while isinstance(x, (list, tuple)):
x = x[0]
return x
reduce(lambda x, y: x + y, operands) # cannot concatenate 'str' and 'int' objects
reduce(lambda x, y: int(collapse(x)) + int(collapse(y)), operands, 0) # 6
reduce(lambda x, y: str(collapse(x)) + str(collapse(y)), operands, "") # '222'
reduce(lambda x, y: x + (int(collapse(y)),), operands, ()) # (2, 2, 2)
reduce(lambda x, y: x + (str(collapse(y)),), operands, ()) # ('2', '2', '2')PYK: OK, I see where you're coming from now , and how the concept of duck typing could be applied to Tcl values , but Tcl's EIAS wonderfulness isn't what Python programmers have in mind at all by "duck typing" . They are primarily thinking about the interfaces of the objects they pass around , and the fact that clients of those objects need not inspect the type of the object , but instead can inspect the interface (method) in order to decide whether or not to work with it . I still think it would be great for the Wikipedia article to have an section about Tcl , perhaps with the title "And now for something completely different ..." ;)
AMG: Yes, Python does have duck typing in the sense that object properties or methods or whatever are late-bound and can be added, modified, or removed throughout the object's lifetime. But that's a rather limited view because the types are still bound to the objects, even if the interfaces can be changed around. In Tcl, types are purely a notational thing, and the interfaces are wholly separate from the objects (values). The EIAS section of my Brush paper summarizes Tcl's relationship with types.