All things in my world seem to be pointing toward ducks lately. I just unlocked the "Quacker" bike in Mario Kart Wii, I got a random sales call from Black Duck Software, and I stumbled upon the concept of duck typing for the first time. All on the same day. I've always been a firm believer, as Red Green often attested, that duct tape is indispensable. But now I'm starting to wonder whether all those years he was saying "duck type". If duct tape is a handyman's secret weapon, should duck typing be a programmer's secret weapon?
So what is duck typing? It's the notion that if something walks (waddles) like a duck and quacks like a duck, then it can be assumed to be a duck. Duck typing, commonly used in languages like Ruby and Python, is a style of typing where an object's current set of methods and properties, rather than its inheritance from a particular class, determines its semantics. Duck typing really isn't all that new - it's really about dynamic versus static typing. Real programming languages like Smalltalk have supported this concept for a long time. ;)
Who decides what the definitive characteristics of a duck are? Does something need to look like, dress like, or weigh as much as, a duck to be a duck (or a witch, as the case may be)? Does it have to feel, smell, and taste like a duck to be a duck? If "beauty" is in the eye of the beholder, does the beholder get to decide what a duck is? Is it a matter of perception?
After reading about duck typing, I got to thinking that it might be one approach to resolving the issue of unintended inheritance in UML. What if, rather than specializing metaclasses from a common infrastructure, or merging them into a hybrid representation using package merge, related languages could simply declare what they assume the definitive set of shared characteristics for each metaclass (duck) is? Should a metamodel perhaps be simply a selection of mixins rather than a complex heirarchy of (base) classes?