Re: Inverse Operation of Module#include

On Fri, Dec 2, 2011 at 7:47 PM, luke gruber <[e-mail]> 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