Re: qualms about respond_to? idiom

In article <[e-mail]>,
Dave Thomas  <[e-mail]> wrote:
>David Alan Black <[e-mail]> writes:
>
>> I'm cool with Ruby's emphasis on object interface rather than type.
>> The only thing is...  I just can't get myself to be happy about this
>> idiom:
>> 
>>    if obj.respond_to? "method" then obj.method end
>
>This is an interesting topic. Just to make sure we're talking about
>the same thing, can I start with a question.
>
>When do you need to check the protocol of an object like this?

You're asking David, but I've got an example...

Users of the TaskMaster Framework can define their own task objects which 
must have a 'run' method defined.  There are a few other optional methods 
that can be defined in a task's class as well and if they are defined they 
get called on the task as it is passed from master to slave.

A couple of examples:

If you define a method in your task class called 'get_serversideTimeout' 
that method will be called in SlaveProxy (on the master side) so that a 
timer is setup prior to sending the task object out to a slave. 

Another example:
If you define a method in your task class called 'pre_run_init' it will be 
invoked on the task after it arrives at the slave machine.

In both cases these are optional methods that can be defined for a task 
class and I use 'respond_to?' to determine if a task object responds to 
them.  I really don't have a problem with using 'respond_to?' this way.  
As an alternative, task classes should mixin a module called 'Runnable', I 
suppose that I could do:
module Runnable
  def pre_run_init
  end

  def get_serversideTimeout
  end
end

Which would define empty methods which could be overridden.

Phil