HI -- On Tue, 22 Jul 2008, Dean Wampler wrote: > On Mon, Jul 21, 2008 at 5:09 PM, David A. Black <dblack / rubypal.com> wrote: > >> Hi -- >> >> On Mon, 21 Jul 2008, Robert Dober wrote: >> >> On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <dblack / rubypal.com> >>> wrote: >>> >>>> Hi -- >>>> For true duck typing you would just do: >>>> >>>> s.the_method >>>> >>> In the general case thats seems clumsy to me, I'd rather check if a >>> protocol is implemented. A very simple example is an IOArray I use to >>> capture output, it mocks two file methods #puts and #<<. >>> What would you prefer? >>> ... >>> >> It depends, though. I could imagine a situation where you really don't >> want to proceed until you've got at least some assurance that an >> object will respond as you want, because you're going to change some >> state in another object. I wouldn't like to see everything wrapped up >> in response checks.... >> > > I prefer the ruby way; That's a bit of a conversation-stopper :-) > let my automated tests confirm that the required methods are present > when I include a module in another module, where the included module > expects the including module to respond to a set of methods. Also, > the tests document the behavior for the users! Sure, no reason not to test everything. I think you may be misunderstanding my point, though (which certainly wasn't that one shouldn't write tests :-) I'm very skeptical about the usefulness of respond_to? in cases where calling the method is going to raise an error anyway. I guess if it's a matter of this: raise unless obj.respond_to?(:meth) do_something_irreversible obj.meth # Disaster if we blow up here. then it makes sense at some level because you can't roll back. But I'm having trouble thinking of a real example. David -- Rails training from David A. Black and Ruby Power and Light: Intro to Ruby on Rails July 21-24 Edison, NJ * Advancing With Rails August 18-21 Edison, NJ * Co-taught by D.A. Black and Erik Kastner See http://www.rubypal.com for details and updates!