This article was modified from its original published form. The most recent modification was on2014-09-26.
Ola Bini is a smart guy. He released a gem that called Ducktator. On ruby-talk, a number of people objected to the characterization of something that does class and method validation as “duck typing”.
I was among that number. It’s cutely named (I like puns), and several people had suggested that it would be useful to them. Whatever value Ducktator1 may have provided, it wasn’t what I considered to be “duck typing” and I thought it would confuse matters worse, overall.
Ola was surprised at the responses; a couple dozen posts in, he decided that he didn’t want to continue the discussion in this venue, and posted his final say on the matter, which linked to a blog post that was a bit less than kind. The smart thing to do would have been to leave it alone, but instead I wrote a similarly unkind post. We acted like adults and resolved our conflict—and edited our blog posts to not include the more inflammatory parts.
What is Duck Typing?
The simplistic answer to this, of course is, “if it walks like a duck, and it quacks like a duck, then it must be a duck.” This is certainly true, but the real question is more “how do I know if I’m duck typing?” Many people, myself included, consider duck typing a matter of trusting one’s callers and documenting your API well enough to ensure that the callers can trust that you won’t do something they’re not expecting. The canonical example of this is a logger.
class SimpleLogger def initialize(recipient = nil) @out = recipient || $stderr end def log(message) @out << message end attr_reader :out end l = SimpleLogger.new() l.log "Hello"
SimpleLogger simply trusts its users to give it recipient classes that
#<<. This is a simple case, but what about something a little
Text::Format can accept a hyphenator object, which must
implement a particular method that has a particular arity. When you assign a
Text::Format does object signature validation for both
the presence of the
#hyphenate_to method and its arity (either two or three
parameters). I consider
Text::Format’s approach less duck-typed (possibly
even not duck-typed, although it is more dynamic than class-based
validation) than I consider the
SimpleLogger class above. Both are useful
techniques—I implemented the validation on
I wanted failure earlier in the execution of
configuration, rather than formatting).
That’s OK, though. The increased complexity of the API for hyphenation suggests that validation is not a bad thing. When you get into the realms of problems that Ola wrote Ducktator for, you need even more complex—and arguably less flexible—validation.
I’m not Dave Thomas (he and Andy [Hunt] applied the term first to Ruby, as far as I can tell), but as far as I’m concerned, object signature validation is not duck typing. It never has been, and it never will be. It’s object signature validation. I don’t care whether you do object signature validation by the class of the object (in which case you’d usually be unnecessarily restricting yourself in Ruby) or by the actual method or methods you need, you’re still not doing duck typing.
Matz disagreed with my strictness, noting that “signature validation is approximation of type-by-behavior”.
Why does it matter?
Whenever people get into discussions about semantics, it’s traditional to mention Alice’s conversation with Humpty Dumpty in Through the Looking Glass.
“I don’t know what you mean by ‘glory,’” Alice said.
Humpty Dumpty smiled contemptuously. “Of course you don’t—till I tell you. I meant ‘there’s a nice knock-down argument for you!’”
“But ‘glory’ doesn’t mean ‘a nice knock-down argument’,” Alice objected.
“When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.”
Eric Mahurin noted that there’s a number of possible definitions for duck typing, so it’s understandable that people find themselves confused. This confusion is the entire reason that semantics matters. Especially as we welcome new people to the Ruby community, it’s important that we try to be consistent and encourage people to use the words in the same way that we use them, for greater clarity2.
- 2014-09-26: This post has been heavily changed from the last vesion in 2006, starting with the title. I think that there are lessons and concepts here which still apply, but I think they needed even more polishing than I did aftermath of some pretty hasty and ill-considered words. I have also provided more context given that this is eight years later.[ back ]