Forward reply to the list... seems like something has changed in the
Gmail interface and I have not yet adapted to it.

Am Do., 23. Juli 2020 um 20:01 Uhr schrieb Robert Withers
<robert.withers at pm.me>:
>
> Although the Promise defined in Kernel-Processes has #wait protocol, this is really an anathema to Promise-style control flow. The #whenResolved: protocol should be used to register a reactor and no waits should occur.
> [...]
> Promise-style control flow does not use mutexes nor semaphores. So I believe the fundamental model here is misused.
> [...]
> So it is your intention to "move away from promise-style control flow." then I would suggest not using a Promise.
>

That's right, but right now I have some dialogs implemented in a
Promise style and want to implement a use case without promise style,
so I have to literally adapt when invoking the dialog if I don't want
to write all of it anew immediately.

Our current Kernel Promise is a two-headed beast: for one it wants to
be a Promises/A+ implementation, but originally it's purpose seems to
be only to support #future sends. Promises/A+ is targeted at
asynchrony in single-thread languages like JavaScript, while futures
are for multi-thread languages like Smalltalk. So Kernel Promise now
tries to serve both single-thread computing (UI process only) and
multi-thread computing (multiple Smalltalk processes).