From: "David A. Black" <dblack@...>
Date: 2003-11-20T03:27:00+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types)

Hi --

On Thu, 20 Nov 2003, Sean O'Dell wrote:

> On Wednesday 19 November 2003 03:55 am, dblack@wobblini.net wrote:
> > On Wed, 19 Nov 2003, Thien Vuong wrote:
> > >
> > > Uh...  If we're getting there the equivalent argument would be
> > > "respond_to?" would not tell you anything except that it respond to
> > > "respond_to?" :).  Unless we agree on some basic contract that a method
> > > need to satisfy (knowing that it could be changed - mind you), it is
> > > pointless to go one way or another.
> >
> > OK, let me rephrase that one :-) The thing you need to know is the
> > object's interface -- which, this being Ruby, has the potential to
> > change.  respond_to? gives you some of that information, very close to
> > the moment of calling a method.  kind_of? doesn't.  Therefore,
> > kind_of? is more remote from the problem than respond_to?
> 
> Actually, kind_of? is far more informative.  kind_of? indicates that
> it belongs to a pre-described interface (a contract), with a fixed
> collection of methods with parameters which are also known.
> respond_to? only tells you an object has a method of a certain name.
> In another post I just made, I gave this example:

A Ruby module or class is neither a contract, nor a fixed collection.
I really don't think, for example, that what Betrand Meyer meant by
"design by contract" was Ruby classes :-)

What you're doing is pressing the closest thing Ruby has to something
that *looks* like the kind of type-checking you want (i.e., kind_of?)
into service as a type check, which it isn't.

Quite honestly, the part I don't get about all this is: why?  It's not
a type check; it is not at all rigorous; and believing in it involves
sweeping under the carpet one of the central design features of Ruby.


David

-- 
David A. Black
dblack@wobblini.net