From: Paul Brannan <paul@...>
Date: 2002-02-14T03:38:41+09:00
Subject: Re: qualms about respond_to? idiom

On Thu, Feb 14, 2002 at 03:10:11AM +0900, Matt Armstrong wrote:
> Examples of this kind of thing abound in OO languages.
> 
>     Ruby's Hash needs a 'hash' method on the objects it stores.
> 
>     Ruby's Array needs a <=> operator on the object (this also takes
>     care of your binary tree example).
>
> This isn't unnecessary coupling -- without these methods, the
> Hash/Array would have no idea how to handle the objects they contain.

For builtins, I think this is justifiable, because Matz can just say
"this is what this method name means; if you use that name to mean
something else, then too bad for you."  But library writers generally
don't have that luxury; if two library writers happen to pick the same
name for two methods that do similar but different things, then that is
a problem.  An object that has a method "foo" might work with library A,
but not with library B, just because of the way "foo" is written to
work.  This may not be obvious, though, to someone who is simply
browsing the code.

> You could make a similar argument for handle_stack.  But I agree that
> sometimes this can be taken too far -- handling this particular NXQML
> problem polymorphically ends up spreading the details of how the stack
> is processed all over the place.  This may very well reduce
> maintainability more than "branching on interface" by using
> responds_to?.
> 
> 
> -- 
> matt