From: Mark Wilden Date: 2008-05-29T14:59:42+09:00 Subject: Re: The duck's backside On May 28, 2008, at 8:59 PM, Avdi Grimm wrote: > 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. I must respectfully disagree. I learned OOP (in 1989) before C++ was even hardly available on PCs, much less Java. The OOP language I learned was an amalgam of Smalltalk and Lisp. I cut my teeth on Bertrand Meyer, Adele Goldbert, Brad Cox, and Grady Booch. I can say quite categorically, that in OOP, classes are ways to generalize. You generalize based on characteristics and behaviors. A class is not simply a random collection of methods. It would be rather useless if class was unrelated to category. But I'm finding these remarks about "attititude" kind of amusing. It's like Ruby isn't a tool, it's a "mindset." We don't forgo something like Numeric === v because it's _wrong_ (the OP in fact said it was slightly more readable), but because Ruby has duck-typing, and why use Ruby if you can't duck type? I hope I'm not the only person to see how totally back-asswords this kind of argument is. > Not everything which behaves as a number will inherit from Numeric, > so that makes it useless and potentially misleading as a > categorization tool. And not everything that implements #to_int will be numeric, or can even be converted to a number in a meaningful way for a context that expects numbers. It's implementer's choice. However, the use case might be that any object with that method is fine and dandy. In that case, I totally agree that checking for response to it is reasonable, if not 100% reliable. But if we're looking for Fixnums, Floats, and other builtin classes, then checking again Numeric seems straightforward. The presence of a method called #each does not make an object iterable. The only way that would be possible is if everyone who wrote an #each method decided that was what it meant. What does show far more accurately whether it's iterable is whether it includes Enumerable. Including Enumerable shows that the #each method is for iterating, rather than pricing, or something else. > 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. True. And often the most straightforward and fundamental way to do that is to call its #class method. I like duck-typing. It distinguishes great OOP languages like Smalltalk and Ruby from wannabes like C++ and Java. But classes are not simply random collections of methods. Their power is indeed to categorize and generalize objects, which can be specialized with inheritance (another old school concept, I suppose). So if I can solve a programming problem simply by asking what builtin class an object is, as opposed to seeing if it responds to a certain method name, knowing nothing about what that method actually does, I'll go with the former. It's just the simplest thing that could possible work. But wait--maybe that hoary criterion is out of fashion too? ///ark