Tom Morgan wrote:
I was rummaging around in the Morphic stuff, and it is plain that there is going to be lots more pluggability in the interfaces.
The current Smalltalk idiom for such things is to specify a #symbol to perform the plugged in action.
Before alot more pluggable this and thats are made, I was wondering if it is worthwhile to consider changing the idiom, to instead pass in a block to evaluate as the standard way of doing pluggability?
I'd like to put out another possibility. Rather than trying to decide should it be selector symbols or should it be blocks, why not use polymorphism to allow either?
Make it possible for the plug to be either a selector symbol to be performed, a message to be sent or a block to be performed. This could be accomplished either by overloading #perform: to do this, or creating a new selector for this purpose (perhaps something like #evaluate: ?) and then having that be used by all the invocations of pluggable behavior.
Using #evaluate: as an example, one could do something like:
Object >> evaluate: anEvaluatableObject ^ anEvaluatableObject evaluateWith: self
Symbol >> evaluateWith: receiver ^ receiver perform: self
BlockContext >> evaluateWith: argument ^ self numArgs = 1 ifTrue: [self value: argument] ifFalse: [self value]
Message >> evaluateWith: receiver ^ self sendTo: receiver
Using a new selector, like #evaluate:, would of course, necessitate changing all the places where pluggable actions are evoked. Alternatively, the above could be called from #perform:withArguments: rather than generating an error when the selector isn't a Symbol. I guess there are pros and cons to either way.
Comments on this approach to generalizing pluggable behavior?
------------------------------------------- Bill Dargel wdargel@shoshana.com Shoshana Technologies 100 West Joy Road, Ann Arbor, MI 48105 USA