Someone suggested that the discussion of what duck typing is is getting
away from how it was originally used.
Perhaps I’m confused, or I’m not explaining what I think in the correct
way, so I’ll try again.
Maybe a better way of phrasing the concepts of duck typing is contract
typing.
If you look at Java, interfaces more-or-less define contracts between
objects. If you have an interface Appendable, that’s a contract that
says an object will
a) Have a method append()
b) Implement that in a certain way
a) can be had in Ruby via respond_to?, the use of which isn’t required
for duck typing. b) can be had more explicitly by using modules.
However, modules, in my mind, are more for reusing code between class
hierarchies without requiring multiple inheritance, rather than for
defining what methods an object implements (although they could be used
for the latter).
If you really want to talk about duck typing, you’d be talking about an
example along the lines of:
def add_elements(foo)
foo << "a"
foo << "b"
end
This method accepts an array (foo) and adds two elements to it using the
append operator. However, looked at more abstractly, this method takes
any object for which << implies append in an array sense. We could
actually pass in a binary search tree where << adds an element to the
three, and it would work in a similar way. If we pass in a Fixnum where
<< is bitwise shift, then we’ve broken the contract.
In Java, you need interfaces for this. You could write:
void addElements(Array foo)
{
foo.append(“a”);
foo.append(“b”);
}
void addElements(BST foo)
{
foo.append(“a”);
foo.append(“b”);
}
But it’s easier to have both implement Appendable, and have addElements
work on anything that is Appendable. Java needs interfaces because of
static type checking. In ruby you can just assume that an object
implements things correctly and use it as such, which, I think, is the
idea of duck typing.
If you want to make it more general, you can add a respond_to? :<< and
respond_to? :append, since different objects might implement either or
both of those. However, the key idea is that in ruby, the contracts are
dynamic. Using Java interfaces, to some degree, forces you to follow
the contracts more explicitly, since you have to knowingly say you
implement a contract and continue to break that contract. However,
assuming that the contract is documented somewhere in the code, and
everybody follows that contract, then there is no need to explicitly
define modules or classes just to define the contract in code, rather
than leaving it in documentation. If you do define modules for each
semantic, then you end up with each of your classes including 10
different modules just so that code can check and see if a class follows
some contract (look through the Java standard library and you’ll see
many classes like this). You’re effectively turning ruby into a
statically typed language where all the type checking is done by you at
runtime.
So another way of saying “duck typing” is “programming with implicit
contracts” or “implicit contract typing” or something like that, rather
than Java, where implicit is replaced with explicit. This is really
something of a feature of any language that isn’t statically typed. The
difference in the case of ruby is that, although you can check the class
of an object with is_a? (or something like that), there’s no way to tell
from the class itself whether it will satisfy the contract. You have to
assume it does.
So having respond_to? :quack doesn’t make it a duck. It’s also how quack
is implemented, and there’s no way to really check that without
testing. Duck typing means making assumptions.
Anyhow, that’s my take on it all, at the end of the day. I hope I’m not
too off base. If I am, then Dave can yell at me.
