From: Eleanor McHugh Date: 2008-05-29T13:45:04+09:00 Subject: Re: The duck's backside On 28 May 2008, at 23:23, Mark Wilden wrote: > On May 28, 2008, at 1:44 PM, David Masover wrote: >> I think it would be :to_i, actually... And I'd probably just call >> foo.to_i, >> rather than testing for the existence of to_i. > > :to_i is actually rather different, as it will convert a string > (even a non-numeric string like "2a"). That's an example of having > to know the implementation of the method to determine whether > testing responds_to? makes sense. For all I know, :to_i may in fact > be the desired method, but Elizabeth used :to_int, and I assume it > was for a reason. I used to_int because it happened to be the synonym that popped into my head at the time I was writing the code. It probably makes more sense to use to_i though as that's often implemented outside the Numeric class hierarchy for objects which can be represented by an integer. >> Also, context matters. If Cowboy and Artist are both in a GUI >> widget library, >> that Cowboy is asking for trouble. > > That's true, but it wasn't my point. The question is whether all > methods with the same name in all active classes should be > semantically equivalent. I think that's a rather larger assumption > than that Numeric means "numeric." Numeric may well mean "numeric" in some particular sense, but that is only a subset of all objects which may have a valid numeric representation. As I said, you're applying a static typing mindset to a place where it's not necessary and whilst Ruby will let you do that, in the long term you'll find yourself doing much more work with very little (if any) gain in software robustness. In fact if you're writing a library you'll introduce additional fragility to code interfacing with it because Ruby programmers generally expect Duck Typing and write accordingly. Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net ---- raise ArgumentError unless @reality.responds_to? :reason