From: Dean Wampler Date: 2008-07-22T07:29:11+09:00 Subject: Re: protected members or explicit abstract classes? ------=_Part_61583_20320692.1216679681214 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jul 21, 2008 at 5:09 PM, David A. Black wrote: > Hi -- > > On Mon, 21 Jul 2008, Robert Dober wrote: > > On Mon, Jul 21, 2008 at 2:37 PM, David A. Black >> 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; 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! However, here's an idiom you could use to ensure that the methods "exist", at least at the time one module is included in other. Assume you have: module A include B ... end and assume that B expects A to respond to "doit". You can override Module#append_features: module B def append_features(including_module) unless including_module.respond_to?(:doit) raise ProtocolViolation.new("#{including_module} must respond to #doit") end super end ... end dean -- Dean Wampler http://www.objectmentor.com http://www.aspectprogramming.com http://aquarium.rubyforge.org http://www.contract4j.org ------=_Part_61583_20320692.1216679681214--