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).