Sabine van Loon said: 
> $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.
> 

This sounds similar to the stuff Digitalk did when they revised their
Smalltalk system for Dos/Windoze.  My biggest problem with that was that
their documentation and browser capabilities weren't upgraded along with
the change, and I found it very difficult to make the change from the 
early ST/V-dos methods, similar to current Squeak, to the new scheme.  I hasten
to add that I was working full time in C/C++, and trying to port my stuff
from ST/V-mac to the second version of it in my spare time -- and my brain
exhausts after a while -- playing a game becomes more attractive that
trying to climb back on that learning curve...


Hmmm... I have the glimmer of a project idea -- an ApplicationBrowser that
lets one browse the responses to various #changed: messages in an
application...  Does such a browser already exist?    I recall adding (in
ST/Vdos)  the ability to click on a window and open an inspector on the
associated TopPane/View - which provides access to the Model, etc.  That's
a start.... 

joe