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.
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
squeak-dev@lists.squeakfoundation.org