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:

obj.respond_to?(:open) => true

...so how do you call open?  You don't know.  Now this:

obj.kind_of?(:socket) => true

...now you know it responds to open, close, read, write, select, etc. and you 
know what parameters they take.  By only testing respond_to? you only know 
that a method is present, but you don't know what parameters it takes.

	Sean O'Dell