<div dir="ltr"><div dir="ltr">Am Do., 16. Jan. 2020 um 09:03 Uhr schrieb Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">Christoph.Thiede@student.hpi.uni-potsdam.de</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>

<div id="gmail-m_8809456479830269324divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:12pt">> </span><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:12pt">Similar alternative without promises:</span><br></p><div id="gmail-m_8809456479830269324Signature"><div id="gmail-m_8809456479830269324divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols"><div name="divtagdefaultwrapper"><div><div id="gmail-m_8809456479830269324Item.MessagePartBody"><div>> - Instead of a promise, store a MessageSend in the model.</div>
<div><span style="font-size:12pt">> - In the client of the model, store all necessary state to continue in instance variables.</span></div>
<div>> - Do not expect a return value from opening the view for the model.</div>
<div>> - Have the model send the message to self upon continuation.</div>
<div><br>
</div>
<div>And I would append observer pattern to this list, which is just a special case of your last point.</div>
<div><br>
</div>
<div>These proposals actually appear a bit easier and more convenient.</div></div></div></div></div></div></div></div></blockquote><div><br></div>Actually it was just a single proposal consisting of multiple steps. :-)<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="gmail-m_8809456479830269324divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><div id="gmail-m_8809456479830269324Signature"><div id="gmail-m_8809456479830269324divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols"><div name="divtagdefaultwrapper"><div><div id="gmail-m_8809456479830269324Item.MessagePartBody"><div>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: ...</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>To simulate the synchronous interface, you must not only notify the client, but also block the calling process until the dialog is closed.<br></div><div>Quick ideas:</div><div>- I have never used it, but I heard Seaside implemented proper continuations. Maybe take a look there.</div><div>- Hacking about thisContext sender or/and suspending the process and resuming it later. </div><div>- 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.</div></div></div>