Am 29.10.2013 um 10:56 schrieb Frank Shearar <[email protected]>:
> If you're going to even think of using callbacks like they do in > Javascript, strongly reconsider. Especially so since the Javascript > community are abandoning callbacks in favour of promises, especially > of the A+ sort. > Well, callbacks are still used but managed by promise objects. Without building composites of callbacks the programming style will turn into „fire & forget“. With using this style of promises you get back a sort of sequential programming model while being asynchron or even parallel. IMHO that is the same thing we are facing from time to time. We like to have things happen in parallel while the programming model is still single threaded. > (Squeak has such Promises in the base image, and if anyone's > interested I can break them out into a Pharo-consumable library.) > That would be really great! I would appreciate that a lot. And btw. I was glad I’ve found your blog post about delimited continuations. Good work! Norbert > frank > > On 29 October 2013 00:11, Sebastian Sastre <[email protected]> > wrote: >> you can do stuff like that, just not sync (which when it's about networks is >> a good idea) >> >> sounds like you should design things javascript style. >> >> I mean, like if "everything" is a callback reacting to something.. >> >> yourAPIClient sendCommand: aCommand do: aBlockHandlingResponse >> >> my 2 cents >> >> >> >> >> On Oct 28, 2013, at 8:50 PM, Norbert Hartl <[email protected]> wrote: >> >>> I’m working on project that deals with server to server communication. For >>> the test suite it is necessary to simulate the two ends of the >>> communication within one test. The problem is that in a single threaded >>> environment you make a send call SC from server A to B but the response of >>> B will happen before SC returned. That makes every state change the happens >>> in A after SC bogus from a call flow perspective. >>> >>> There are two approaches that have their own problems. >>> >>> 1) Until now I’m reordering parts of the call stack to simulate the return >>> of a call before the actual call is sent. But now I have nested sends that >>> make my simple approach not working anymore. I could elaborate my approach >>> by using something like delimited continuations to make a less brittle >>> approach to stack call reordering in order to cope with the problem. That >>> would need some work and the stack in the debugger will look a little bit >>> odd/confusing. >>> >>> 2.) The product will later have a dispatcher process that dispatches each >>> send operation in its own process. That would solve one problem: the timing >>> of when actions happen. But I’m not sure if it will be easy to orchestrate >>> actions in a way that I would call controlled in order to have reliable >>> tests. >>> >>> Are there any approaches to simulate coroutines in a single thread >>> environment or approaches to deal with multiple processes within one >>> process? >>> >>> It is hard to explain and I hope my description of the problem is >>> understandable >>> >>> thanks in advance, >>> >>> Norbert >> >> >
