From: Austin Ziegler Date: 2006-09-21T00:49:43+09:00 Subject: Re: Ducktator - A Duck Type Validator On 9/20/06, MonkeeSage wrote: > By asking if object O respond_to? method M, we can impose certain > conditions, and raise an error if those condition aren't met, rather > than raising a runtime error in the middle of the program or getting > wonky behavior. I.e., think of it as pre-emptive TDD. This isn't > _necessary_ for duck-typing, but it certainly seems to be an extension > of it. Do you want your object, O, to act like a file? Then you better > make sure that it respond_to? read() and write()! No, you better not. If I use #<<, then I can "write" to a String, a StringIO, an IO (socket, file, etc.), or an Array. Checking for #write limits you to (mostly) actual IO objects. Reading is a little harder, but I tend not to bother checking for that -- I generally just call #read and tell people in the API that #read will be called at some point and it better return something useful. It isn't preemptive TDD to do validation, and in Ruby ALL errors are runtime. Method presence validation is useful and sometimes necessary; if you look at Text::Format, you'll see that I do both method presence and arity validation for hyphenator objects on assignment. But I don't pretend that this is anything *but* runtime checking. -austin -- Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca