P
Paddy
Hi,
The wikipedia article on Duck Typing has this criticism section that
needs a citation:
(Fron: http://en.wikipedia.org/wiki/Duck_typing#Criticism)
An often cited criticism is this:
One issue with duck typing is that it forces the programmer to
have a much wider understanding of the code he or she is working with
at any given time. In a strongly and statically typed language that
uses type hierarchies and parameter type checking, it's much harder to
supply an unexpected object type to a class. For instance, in python,
you could easily create a class called Wine, which expects a class
implementing the "press" method as an ingredient. However, a class
called Trousers might also implement the press() method. With Duck
Typing, in order to prevent strange, hard to detect errors, the coder
needs to be aware of each potential use of the method "press", even
when it's conceptually unrelated to what he or she is working on. With
type checking and hierarchical type declarations, all wine ingredients
would be subclasses of WineIngredient or something like that, negating
the problem.
In essence, the problem is that, "if it walks like a duck and
quacks like a duck", it could be a dragon doing a duck impersonation.
You may not always want to let dragons into a pond, even if they can
impersonate a duck.
In practice, the issue is equivalent to not mixing dissimilar objects
for duck-typing and is handled almost transparently as part of the
knowledge of the codebase required to maintain it.[citation needed]
I've only found this so far as a citation:
http://jessenoller.com/2007/05/30/typeducking-on-duck-vs-static-typing/
Whilst it is good, do you know any other work that refutes the
criticism?
(I, and many others don't see the problem, but who has written about
it).
Thanks, Paddy.
The wikipedia article on Duck Typing has this criticism section that
needs a citation:
(Fron: http://en.wikipedia.org/wiki/Duck_typing#Criticism)
An often cited criticism is this:
One issue with duck typing is that it forces the programmer to
have a much wider understanding of the code he or she is working with
at any given time. In a strongly and statically typed language that
uses type hierarchies and parameter type checking, it's much harder to
supply an unexpected object type to a class. For instance, in python,
you could easily create a class called Wine, which expects a class
implementing the "press" method as an ingredient. However, a class
called Trousers might also implement the press() method. With Duck
Typing, in order to prevent strange, hard to detect errors, the coder
needs to be aware of each potential use of the method "press", even
when it's conceptually unrelated to what he or she is working on. With
type checking and hierarchical type declarations, all wine ingredients
would be subclasses of WineIngredient or something like that, negating
the problem.
In essence, the problem is that, "if it walks like a duck and
quacks like a duck", it could be a dragon doing a duck impersonation.
You may not always want to let dragons into a pond, even if they can
impersonate a duck.
In practice, the issue is equivalent to not mixing dissimilar objects
for duck-typing and is handled almost transparently as part of the
knowledge of the codebase required to maintain it.[citation needed]
I've only found this so far as a citation:
http://jessenoller.com/2007/05/30/typeducking-on-duck-vs-static-typing/
Whilst it is good, do you know any other work that refutes the
criticism?
(I, and many others don't see the problem, but who has written about
it).
Thanks, Paddy.