[Apologies to anyone whose threading is getting messed up by the appearance and disappearance of those long message id strings.... I'm not sure where they came from.] Hi -- On Wed, 19 Nov 2003, Thien Vuong wrote: > dblack / wobblini.net wrote: > > > kind_of? has no connection to respond_to? except that you learn > > whether or not the object responds to "kind_of?" :-) So the cost you > > pay -- that the response to kind_of? has to pass some test of > > name-membership -- in most cases gets you little or nothing. > > > > 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? Mind you, I'm not trying to advocate calling respond_to? before every other method call. There are many other things one can do to accomodate and leverage the inferential typing of Ruby objects, including exception handling and unit testing. I also agree with Jim Weirich that what's really at stake here is not a large likelihood that, say, a String won't respond to #split when you think it will (though that is certainly always possible in a language that does not have a tight coupling between class and type), but rather the potential cutting off of interesting design possibilities. Not that every time one writes a method one has to come up with an interesting design :-) But still, I think Jim is right that that's where the rewards lie. David -- David Alan Black home: dblack / wobblini.net # New email address work: blackdav / shu.edu Web: http://pirate.shu.edu/~blackdav