On 2006/12/29, at 23:50, Phrogz wrote:

>   def method( a )
>     entry_check{
>       raise "OUCH" unless a.is_a?( String )
>     }
>     # meat here...
>     exit_check{
>       # ...
>     }
>   end

It's quite possible to think that the raise is, in fact, "assert  
a.is_a? String", reenforcing that this is quite the same as testing  
arguments on the fly, with each method call. OTOH, isn't this  
remarkably similar to static typing? Think of the java's interface  
hell (having to implement enormous amounts of interfaces in one  
class). We're just delegating type checking to pre-call tests,  
assuring that the duck we're receiving as an argument can quack as we  
would except it to. I think type checking is not such a good idea.  
This kind of mechanism should assert if the behavior of the arguments  
makes them plausible to be arguments. I'll try to exemplify.

Consider a method that prints the length of an object (obj.length) in  
roman numerals. If the object doesn't have the length method, the  
method should degrade gracefully and exit without printing nothing.

Consider a "Project" object that can only have a manager that has, at  
least, 5 years experience. In this case, the method should raise a  
NotEnoughExperienceException.

Putting it in a _why-ish way, the pre-call tests should not check if  
your duck can quack but instead test that that quack's pitch is high  
enough for the method to be applied to it.

These are just my humble opinions. Not authoritative in any way.

Note: this is beginning to look like formal methods of ensuring code  
and runtime correctness. History has it that they're always resource  
consuming and it's cheaper to read the documentation, sanitize inputs  
and code in a properly fashion.