Tom you wrote: 

[snip]
> 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 am not a fan of using the #symbol approach for pluggability. A block
would be better but is still limited. Although I am biased (because I am
using it) I think VSE event approach is much better. In this approach each
class defines the events its instances can generate and let the client of
such an instance determine what to do when it happens. Suppose you have a
Order class which defines the following events: #newOrderLine: (generated
when a new order line is added to the order, the parameter is the order
line), #delivered (generated when the status is changed to delivered).
A client can then register interest in these events like this:

someOrder when: #newOrderLine: send: #updateTotal to: someWindow.
someOrder when: #delivered send: #add: to: deliveredOrders with: someOrder.
someOrder when: #delivered send: #message: to: MessageBox with: 'Order
delivered'.

As you see, the messages #when:send:to: and #when:send:to:with: are used to
register the interest. In this case the parameter of #newOrderLine: is
passed as the first parameter of #updateTotal:. This is builtin-in
functionality. Furthermore, you can have multiple event handlers for an
event (2x #delivered)

You could argue that this is a variant to the #symbol mechanism but it is
more powerful than that.
I am even planning on extending the compiler to recognize 'event' as a
keyword (like super) for triggering an event. There's no real need for that
of course but it keeps me from typing 'self triggerEvent" #delivered').

BTW Somebody already made a change set for working like this.

> There are pluses and minuses to doing this, here is my list (with some
> schizophrenic comments about my own list)
> 
> Blocks to evaluate are a good thing
> -----------------------------------
> 
> -There may be no need to make a method to handle the pluggablity
>  action, you can do what you need right in the block.
It's a plus that you don't have to make a method.

> 
> -(For pluggable actions that need to be fast) it is easier to
>  imagine tuning up methods that have real 'static' sends in the
>  pluggable block, rather than some scheme that makes 'perform'
>  run fast.
>   
>  Objection:  most pluggable things don't need to 
>              be fast.  
>  Yeah but:   the pluggable action inside of things
>              like sliders and drag 'n drop would 
>              benefit from being fast.
I hope the 'event' keyword implementation is faster than an ordinary send.

[snip]
> -It would be easy and 'thin' to provide an interface that accepted
>  the #symbol kind of pluggablity, by simply sticking the 
>  symbol in a block to evaluate and passing that to the block
>  argument interface.
True.

[snip]
> -(This is a pretty opaque argument).  Using a block is a better
>  match of the moment in time when you know something to the 
>  moment in time you want to use what you know.  That is, 
>  'performing' something is a good match, when you don't know
>  at the calling point what you want until just the instant before you 
>  do the perform;  the passed in block matches the fact that
>  you know what you want to do at the time that you write the
>  method which calls for the opening of the pluggable action.
> 
>  Objection:  What did you just say?
True ;-))
> 
> Blocks to evaluate are a bad thing
> ----------------------------------
> 
> -Anonymous chunks of code are scary and hard to debug.
Very true.

> 
> -The blocks will be hard to track down and revise, in the
>  event they need to be changed; it is better to insist that
>  they be in named methods
Agree.

Cheers, Reinier.