|
Nov 25
2009
|
Duck Typing and the Go Programming LanguagePosted by Christopher Diggins in Programming Languages, Programming Language Implementation, Heron, Go   |
 |
I was reading up on the Go programming language, specifically the language design FAQ (http://golang.org/doc/go_lang_faq.html) and it got me thinking again about duck-typing (signature based polymorphism).
First, I have to strongly recommend that all programmers carefully read the Go language design FAQ. It is a glimpse into the kinds of issues that programming languages designed for the future are going to be doing in the face of rapidly increasing parallelism. The people designing this language, really know what they are doing in many respects, especially when it comes to concurrency.
One thing about the FAQ that intrigued me was the level of excitement over signature based polymorphism (duck-typing). This is clearly one of the most exciting features from the point of view of the language designers (who are also using the language extensively).
In the past I talked myself out of using duck-typing for Heron because I liked the explicit information carried in a class about what it is intended use is for. I was also scared of the possibility of accidentally using classes where the behavior did not match what was expected. Think of the case of a FIFO queue versus a LIFO queue.
Now that I think about it though, I think that perhaps I was just being overly cautious. I realize that I frequently using C++ templates as a poor-man's duck-typing.
Perhaps I should throw caution to the wind, and embrace duck-typing fully? Or maybe I should take a middle of the road approach and provide a form of explicit duck-typing via a duck-typing coercion operator. E.g. "MyFunction(Dog as IInternetUser)".
So what are your thoughts, would you want duck-typing in a language intended for engineering large-scale complex software developed by big teams of developers? Would you like a "duck-typing" coercion operator, and if so what would you name it?
Subscribe to this comment's feed
Show/Hide comments
written by Frank Hileman, November 25, 2009
written by Frank Hileman, November 25, 2009
written by Dan Udey, December 01, 2009
Essentially, you can iterate over a class if it has an __iter__() method that's implemented properly. You can coerce it to a string if it has a __str__() method, and so on. It's handy because I never need to check what type something is ('Is this a list? No? Get lost!'), only how it behaves ('Can I iterate over you? I can? Great!').
Examples: Iterate over a string to get characters. Iterate over a file to get lines. Iterate over a dictionary to get keys. By checking only to see if an object behaves the way I want (vs. checking to see if it is what I expect) it makes my job easier, and simply puts the onus on the programmer using my code (whether that's me or a coworker) to pass me something that my code can work with.
If the idiom in Python were to check types, most of my code wouldn't work, wouldn't be future-proof, or would misbehave in weird ways, and I'd be writing tons of code to check and see if what I've got was any of the allowed (read: previously vetted) types. No thanks.
Show/Hide comment form
