Stéphane Ducasse <stephane.duca...@inria.fr> wrote:
> refrain from using respondTo:
> I make code difficult to evolve and can introduce vicious bugs.
Steph, would you say more about this? It’s something I’ve been wondering about.
I was recently reading the Strategy pattern in the Smalltalk Companion to the
GOF book. On p. 339, they proposed the following "Smalltalk way" as an
alternative to the common class-per-strategy implementation:
\[\[\[language=smalltalk
Composition>>repair
"Without the strategy pattern, but using perform:."
| selector |
"Construct the name of the method to invoke:"
selector := ('formatWith', formattingStrategy, 'Algorithm') asSymbol.
self perform: selector
\]\]\]
It then dismissed the approach as "''clever but difficult from a program
understanding perspective. Even static analysis tools such as code browsers'
"senders" and "messages" fail on this code.''"
It struck me as perhaps a bit extreme (i.e. too clever indeed) to construct the
algorithm selector via string concatenation. Maybe "senders" search
capabilities have gotten more sophisticated since publication, but Pharo seems
to support symbol arguments, even for e.g. message renames. I thought, why not
the following:
\[\[\[language=smalltalk
Composition>>repair
"Without the strategy pattern, but using perform:."
self perform: self formattingStrategy
\]\]\]
Then client code like ==aComposition formattingStrategy:
#formatWithSimpleAlgorithm== would show up in senders, message renames, etc.
But from what you’re saying, I feel I may be missing something…
