You're right. And I have a similar situation in some of my code right  
now, which is why i piped up earlier.  I have two or three examples in  
my code. The first is a container (financial series) that holds  
Numbers or something else. Under mathematical operations, my financial  
series will operate on the numbers only, and simply replace anything  
else with a FaNullDatum (singleton) -- FaNullDatum has its own  
printing/display methods, and it knows nothing about mathematical  
operations.

A second example in my code addresses what is mentioned below. But for  
this aspect, I know that all of the candidate objects were defined  
under a certain tree that implements a #canCompute: method, or that  
objects wishing to be substituted will implement the method. That way  
I don't have to worry about how it is implemented (e.g.  
#doesNotUnderstand:) and whether it will be in the method dictionary.

So... obviously, "existing" objects can be substituted... but now I am  
re-thinking the generality of these objects. Perhaps I can loosen this  
constraint -- even though I am not convinced it would ever matter for  
my situation. (Mine are FinancialAnalyst objects that know how to  
operate on my set of financial data keys.)

... i need to look into Traits.

Ciao,
Cam

On Jun 30, 2009, at 12:46 AM, Igor Stasenko wrote:

> Concerning #respondsTo: - its also smells a bit, because you are
> depending not on a specific behavior (by invoking some method) but
> rather testing the class method dictionary, which is mostly static.
> This approach (use of #respondsTo:) also doesn't fits well with
> proxies (and we need them sometimes).