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 at shoshana.com
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA