Am Do., 16. Jan. 2020 um 09:03 Uhr schrieb Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.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.
>

Actually it was just a single proposal consisting of multiple steps. :-)


> 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: ...
>

To simulate the synchronous interface, you must not only notify the client,
but also block the calling process until the dialog is closed.
Quick ideas:
- I have never used it, but I heard Seaside implemented proper
continuations. Maybe take a look there.
- Hacking about thisContext sender or/and suspending the process and
resuming it later.
- Spawn a new UI process, once the dialog is closed have it signal a
semaphore and terminate itself. Let the original UI process wait on that
semaphore. Breaks other things which don't support such changes of the UI
process, such as the Monticello tools. May have edge cases that leave the
world without an unblocked UI process, I don't know.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200116/cf0956b3/attachment.html>