Yes, this programming style sounds really interesting but totally different. :)

Funny, the only real sender of #future in my image comes from Squot :-)
<http://www.hpi.de/>

> Similar alternative without promises:
> - Instead of a promise, store a MessageSend in the model.
> - In the client of the model, store all necessary state to continue in instance variables.
> - Do not expect a return value from opening the view for the model.
> - Have the model send the message to self upon continuation.

And I would append observer pattern to this list, which is just a special case of your last point.

These proposals actually appear a bit easier and more convenient. I would like to use the same solution for DialogWindows as well which suffer from the same problem. But #inform: should be called as usual and hide any concurrent logic from the caller. How would you identify the object to resume after the information, if you called, for example, nil inform: #foo? I think the only way, without creating an extra DialogWindowModel, would be #spawnNewProcessDuring: ...

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob at resfarm.de>
Gesendet: Mittwoch, 15. Januar 2020 21:39:33
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Monticello-ct.712.mcz

Since you mentioned the #future, I recently tried to wrap modal dialog (well not really, it is not exclusive, it just has a synchronous API to obtain the result) with a promise interface and came up with the following. If I thought it through correctly, it should not lose the continuation even when the UI process is terminated and replaced (via Ctrl+., abandon, for example). Haven't tested it yet, though. Would anyone like to review?

In the model...
selectedChangesWithTitle: titleString
| builder |
builder := ToolBuilder default.
view := builder open: self label: titleString.
promise ifNil: [promise := Promise new].
self future resumeModalRequest. "will resolve the promise"
^ promise

resumeModalRequest
view ifNil: [self error: 'Tool was not opened yet'].
promise ifNil: [self error: 'Tool was not opened with selectedChangesWithTitle:'].
[ToolBuilder default runModal: view]
ifCurtailed:
["Make sure we will notice in a new UI process when the view is closed."
self future resumeModalRequest].
"If we finally get here, the view was closed."
self accepted ifTrue: [promise resolve] ifFalse: [promise reject].

Am Mi., 15. Jan. 2020 um 21:32 Uhr schrieb Jakob Reschke <forums.jakob at resfarm.de<mailto:forums.jakob at resfarm.de>>:
Am Mi., 15. Jan. 2020 um 09:13 Uhr schrieb Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>>:

You proposed using a promise - I never had the pleasure to meet them until today. Maybe you have a minimum working example for demonstrating your proposal? FutureNodes seem to be used very rarely in Trunk :-)

I have no minimum example ready, but here is the outline:
- Add an instance variable for the promise to the model.
- Initialize with `Promise new` when the model is asked to open a view.
- Answer the promise to the open message.
- In the model's method that is invoked when the dialog is accepted, promise resolveWith: theResultOfWhatHappened
- In the method that opens the tool, take the promise and use whenResolved:, whenRejected: (handle the outcome) or then:ifRejected: (handle the outcome and answer another promise -- chaining). Do not attempt to return from the handler blocks, the method will have returned by the time they are evaluated.

Of course it is a totally different style of programming than with modal windows.

Similar alternative without promises:
- Instead of a promise, store a MessageSend in the model.
- In the client of the model, store all necessary state to continue in instance variables.
- Do not expect a return value from opening the view for the model.
- Have the model send the message to self upon continuation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200116/da9a291e/attachment.html>