Tom Morgan said: 
> 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've just been working with elisp and read some remarks about the relative
value of using named vs anonymous functions for hooks, and it seems to me
this is basically the same question.  That is, what's the difference
between a method and a block?  The method has a selector stored in some
method dictionary and the block doesn't.  Evaluating the method, given the
selector, involves a search for the associated block and then evaluating
the block.  So the block is probably faster.  On the other hand since the
block is anonymous it will probably need to be replicated if it needs to be
plugged into several different slots, while the method simply has the
selector duplicated.   Furthermore, because of the way method
identification is done, different classes can use the same selector with
different implementations -- so the same "browser view" can be used by
signifcantly different browsers by providing different methods for the same
selector.   That's probably the biggest argument for staying with selectors.

An alternative mechanism would be to have a Dictionary with blockNames as
keys and blocks as values  (very like a method dictionary?) the key goes to
the pluggable...  If one used Smalltalk, the system dictionary, the keys
are then global -- the search is faster, but there's only one
implementation.  If one uses Class Pools, there's a different set of
attributes.  

Personally, I think I prefer the current implementation because of the ease
of extending the system.


joe