From: Peter Vandenabeele Date: 2011-12-03T07:47:35+09:00 Subject: Re: Inverse Operation of Module#include --485b397dd54735792504b323c151 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 2, 2011 at 7:47 PM, luke gruber wrote: > Peter Vandenabeele wrote in post #1034787: > > > Very curious to hear how this design could be improved with duck typing. > > Correct me if I'm wrong, but I think Steve was trying to say that using > __abstract__ base classes are useless. I mean, it's just there to raise > an exception, but the exception would have been raised anyway (a > NotMethodError). In Ruby, interface is everything, so instead of seeing > if something is a kind_of? Team, just check if it responds_to? :play and > code the interface that way. > Aha, thanks for the detailed reply. Now, just for my understanding of duck typing, assume both derived classes (BaseballTeam and FootballTeam) have a method with the name :play, but they require a different argument signature (like in my put example where MoneyAccount#play needs a BigDecimal and CreditAccount#play needs an integer). Should I then still use the class to determine how to call the method, or should I better name these 2 methods differently? > In your case, the base class is taking care of things that all accounts > do. In my view, this is a fine, and it's not __really__ a ruby abstract > base class because you're not raising explicit exceptions on abstract > methods. In your case, this is just a base class, not an 'abstract' base > class. Abstract base classes have purely abstract methods that are just > useless in ruby. If however, you're providing real implementation > through actual methods that do stuff, this isn't an abstract base class > but just a base class. > OK, got it. So on the criterion of actual functionality, it is not an abstract base class, but still, it is not the intention to ever create an instance of the Base class, only of the derived classes. Thx, Peter --485b397dd54735792504b323c151--