Andreas, I said:
-----Original Message----- From: Withers, Robert [mailto:rwithers@quallaby.com]
I am curious about your use the ivar #myQueue in the ScriptProcess. I really like that your ScriptProcess will compute a value, and that that value is the 'result' of the process. That's a very standard view of computations. Isn't it a functional view? A better approach for supporting eventual sending may be to have a subclass of ScriptProcess which holds the continuation to the invocation site.
Actually, I am now thinking that a subclass may not be needed, since ScriptProcess already holds onto the invoking message (AsyncScriptMessageSend to be replaced by EventualScriptMessageSend for eventual sending) and the owner, which is the same object. There are also the ivars #myHandler and #myEventMap.
In the following method, called when the Process returns from the last stack frame, there are three different mechanisms that we could hook into to activate the resolver.
ScriptProcess>>#stopScriptProcess: result ... owner ifNotNil:[owner scriptStopped: self]. myHandler ifNotNil:[myHandler releaseTo: nil]. myEventMap ifNotNil:[self signal: #done with: resultObj].
- owner is the ScriptMessageSend, so an implementation of #scriptStopped: in the EventualScriptMessageSend, could activate the resolver.
- myHandler is set when sending #observe: and it is an EventObserver. Currently this only looks to be used by the #waitUntil protocols and it blocks on a semaphore. I suppose that a special observer could be created that holds the resolver.
- myEventMap holds event registrations. These can be set at a low-level with #on:notify: or at a higher level by startScript:when:. So after the EventualScriptMessageSend is converted to a ScriptProcess, a registration of the following could wake up the resolver proc on: #done notify: (#resolve: asAsyncScriptMessageIn: self resolver arguments: #())
What do you think would be the best way to activate the resolver?
cheers, rob