Ben Giddings wrote:

> Testing to see if the "read" method is supported is not really "duck typing", 
> in the sense that you're not really checking to see if it's a duck.  Just 
> because the object implements a certain method doesn't mean that that method 
> does what you expect.
> 
> In certain cases, checking to see if a method exists is enough.  The method 
> "to_str" is a prime example.  If someone implements that method in a way that 
> doesn't return a string, they deserve whatever problems they get.  There are 
> plenty of examples of how to_str is used everywhere else, and the function 
> name is pretty descriptive.  Other functions are less obvious.

This is a great summary of the kind of limits I place on relying on duck 
typing.

The name of a method, by itself, rarely tells you everything that you 
need to know about the method's "contract". Don't get me wrong: I /like/ 
the idea of using #respond_to? instead of #is_a? when trying to 
determine an object's capabilities, but am very conservative with this 
approach. If I'm checking for a method name that is extremely well 
established by the standard library, and one for which no one in their 
right mind would change the semantics (e.g. #to_str), then I'll take 
advantage of that. Otherwise I tend to shy away from this approach.

This might be a good thing to document, either on the Wiki or in the 
next edition of Programming Ruby: what are some of the "standard" method 
names that people should be aware of?