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


On Dec 11, 2011, at 11:17 PM, Grary Stimon wrote:

> Yes, I understand your proposed approach.
> 
> I think your approach is better than the one I was playing with, because 
> it's a
> bit lazier and more permissive, for example, in the case the child does
> not override every method 'required' by the parent, they could still use
> it to some desired effect.

Yes. In fact, in this case the example didn't make sense, because I just exchanged one runtime error for the other. But in many cases you actually have some benign good value which you could use (in addition you could print a warning as a reminder that the method should be redefined) in that method 'stub'.

> Yet, under the alternative approach I propose, not even that is required
> -- the documentation suggests it or shared tests require it.

Testing is a good point, actually. I find that when you require mocks or stubs in your tests those instances often arise exactly when there are requirements that are difficult to express, or are expressed only by programming-by-contract type of comments/documentation (e.g., base classes must implement this method, passed in argument must provide a certain property etc.).


> I don't know, though, I think it best to let the code express the full
> intention of the programmer and not augment with optional struts like
> documentation or even tests...
> 
> Grar
> 
> -- 
> Posted via http://www.ruby-forum.com/.
>