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