From: Avdi Grimm Date: 2008-05-29T12:59:04+09:00 Subject: Re: The duck's backside On Wed, May 28, 2008 at 6:23 PM, Mark Wilden wrote: > Well, the desired goal is in fact to recognize objects that are numeric. One > of the purposes of classes in OOP is to categorize things. Not really, no. That reflects an attitude that has more to do with C++ or Java than with OOP. Not everything which behaves as a number will inherit from Numeric, so that makes it useless and potentially misleading as a categorization tool. If you want you know whether an object is in some category in an OO way, you come up with a way to ask it. E.g. if you want to know if an object is iterable, you ask it if it responds to #each. Or you simply treat it as if it is in that category, and see what happens. If you want to *assert* that object to must be in a category, you tell it to convert itself (and it will tell you if it can't). With that said, I'm not really on the fanatical duck-typing end of things either. I believe there is value in doing proactive contract checking at what I will call for lack of a better term "package boundaries". Duck-typing errors are not always obvious or easy to track down. I like to have firewalls that I can be fairly confident will catch faulty assumptions in a straightforward and obvious way, without having to work back along the chain from a secondary or even tertiary side-effect of an object failing to quack. For this reason I've been known to put pre- and post-condition assertions in layers of code that interact with third-party code. -- Avdi Home: http://avdi.org Developer Blog: http://avdi.org/devblog/ Twitter: http://twitter.com/avdi Journal: http://avdi.livejournal.com