From: "Mauricio Fernández" <batsman.geo@...>
Date: 2002-10-08T17:52:46+09:00
Subject: Re: Another take on ensuring right args to methods

On Mon, Oct 07, 2002 at 05:15:05PM +0900, Massimiliano Mirra wrote:
> On Sun, Oct 06, 2002 at 10:43:46PM +0900, dblack@candle.superlink.net wrote:
> > Personally I like #can?  but it doesn't help with the awkward two-headed
> > "obj.meth if obj.can?(:meth)" idiom.
> 
> I know, but I'm still convinced that you'd only want to do that when
> calling meth on obj was totally optional to the logic, which happens
> seldom (at least in my experience).
> 
> > >  class Foo def meth(bar) bar.passes?(TestBar) or raise ArgumentError
> > > end end Foo.new.meth(1) $ ruby --inline-tests foo.rb
> > What does #passes? actually do?
> 
> Actually nothing since it's not implemented :-), but in my mind, it
> would submit the object (or rather its class) to a small ad-hoc test
> suite, which would not only test whether it responded to (for example)
> #read, #write and #seek, but also check whether what gets written with
> #write can be later read with #read.

What if the object represents /dev/null and you cannot read back what you 
wrote previously? It is hard to specify the right minimal semantic
requirements...
 
> It would impose quite an overhead at runtime, but could be executed
> only when a global switch was turned on (--inline-tests), and would
> guarantee that an object really provides some functionality, not just
> `looks like to' as with respond_to? or Java interfaces.

IMHO it is a good idea if some provision is made for "non-standard"
behaving objects. 

-- 
Mauricio Julio Fernandez Pradier