From: Sylvester Keil <sylvester.keil@...>
Date: 2011-12-12T06:56:47+09:00
Subject: Re: enforcing module contract with self.included?

That's an interesting question and I'd be interested to read more opinions on this.

What I've done in the past, is to add the required methods to the module itself. For example, in your case you could add

def birthdate
  raise 'base classes should redefine this method'
end

to your module.

I think the general disdain against strictly type-based enforcements stems from the fact that Ruby is extremely dynamic; by restricting behaviour to certain types you're making it harder (not impossible) to extend the behaviour or to use it in new or novel ways.


On Dec 11, 2011, at 9:45 PM, Grary Stimon wrote:

> OK, right.
> 
> I still can't get the test result I expect in this case...
> 
> But as a general matter, I have noted the general disdain Rubyists have
> for abstract class-like enforcement mechanisms. And it's true that if I
> want to rule out runtime errors by enforcing the presence of certain
> parent class methods in any implementing children, then I've got to put
> all this stuff in the parent to ensure that, as I have been trying to do
> with the Module hooks.
> 
> ALTERNATIVE APPROACH -- which I take to be more Ruby -- is to trust the
> implementer to follow the documentation for the parent -- taking
> responsibility for runtime error stuff, themselves. I might try to help
> them by adding test examples that they can take from my parent module
> and run against their child implementations.
> 
> Is my alternative approach the way to go, or do good Rubyists enforce
> parent module contracts to avoid runtime errors in the implementing 
> children?
> 
> Grar
> 
> -- 
> Posted via http://www.ruby-forum.com/.
>