Here we go. That is an excellent observation, Justin, I see what you mean. I'll try and adjust the diagrams to fit the code examples better.
I'm thinking of ways to make it clear from the get-go. I'm thinking of using terms such as "inter-process RPC", since: 1. Calls act internal to the object 2. Calls reside elsewhere 3. Calls are synchronous Just like RPC. :) However a Request is not a RPC, because they are subscribed to by external objects (observers), like Qt Signals. In fact, the calls act identical to calling upon the local functionality of an object. The Request object might be referred to as a "proxy" around an external object; again, similar to RPCs and services. Ultimately, from the objects point of view, calling a method it owns and calling a method through a Request is identical. The only difference is the external methods doesn't have to exist to begin with, but can come and go, just like with Qt Signals and Slots. As for the diagrams, are you referring to first one? The "graphics" to "logic" using 2 signals? That is indeed an asynchronous design, and I should clarify that this is *a synchronous use of an asynchronous method*. :) Signals *may* be use for async calls, (i.e. one signal could emit, but not necessarily expect one in return, at least not immediately) The use-case I'm attempting to illustrate is for situations where you *want *a response back immediately; when you want something happening remotely to respond to the GUI immediately. My particular use-case is for GUI and logic sitting right next to each other, not leaving any room for delay. Can you see any other use? Thanks again! On 17 April 2014 11:02, Justin Israel <[email protected]> wrote: > I'm just finding the diagrams don't seem to match the code examples. The > examples do suggest a 100% synchronous call. You make the function call and > block until you have a result. In that case, what you have is basically an > abstraction over one function calling and returning the value of another > function in the form of a closure. > > def other(): > return "foo" > > def this(): > return other() > > print this() > # "foo" > > That is a synchronous call, and you block until you get your value. > > But your diagrams refer to two phases, which implies the call is > asynchronous: > > def callmeback(val): > print val > > def other(): > return "foo" > > def this(callback): > enqueue(other, callback) > > this(callmeback) > # do some other stuff. > # eventually this happens: > # "foo" > > Or in the terms of a future: > > future = this() > # do some stuff. > print future.get() > # "foo" > > So is it an async request-reply pattern where you send off a request and > at some point later you expect to retrieve a reply? Or is it a synchronous > request-reply where you send off a request and block until you get your > reply? Because my impression is that either the code examples don't match > the diagrams, or the code examples are correct and its an abstraction > around closures where one function calls another function whose > implementation can be switched out (my function calls something that > contains switching logic to figure out what to really call and return). > > Regarding the twisted thing, I don't think it is what you are after since > it does focus on solving async problems using an event loop and callbacks > as opposed to threading. > > > > > On Thu, Apr 17, 2014 at 8:44 PM, Marcus Ottosson > <[email protected]>wrote: > >> Hi Matt, thanks for the link. >> >> I think the future and promises pattern is mostly for concurrent >> operations, whereas the pattern I'm attempting to describe (although it >> would seem I'm not doing a very good job in doing so :) is a pattern for >> de-coupling components; it is actually synchronous, much like signals and >> slots. >> >> Since both you and Justin find the Request Pattern about asynchronous and >> concurrent operations, I'd like to refine the RFC to highlight that it is >> not. Could you point out to me which part of the document made you come to >> this conclusion? >> >> Thanks a lot >> >> >> On 17 April 2014 08:57, Matt Chambers <[email protected]> wrote: >> >>> Hey there, this is already a thing. No need to reinvent the wheel. >>> >>> http://en.wikipedia.org/wiki/Futures_and_promises >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/3f753ec7-1cc8-4d59-8671-8bf7ebdb3ccd%40googlegroups.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> *Marcus Ottosson* >> [email protected] >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC0O9cVh29_ic7O95NLC21PqRVvyDY265%2BhuHBZbxZGbw%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC0O9cVh29_ic7O95NLC21PqRVvyDY265%2BhuHBZbxZGbw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA11R-UEnWf5DUCHz%2B_KuYJn1Sx66K7CPD3uZFbsJR7VqQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA11R-UEnWf5DUCHz%2B_KuYJn1Sx66K7CPD3uZFbsJR7VqQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *Marcus Ottosson* [email protected] -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC-xcZrtkMoEyTtwVPu9F38BVkVRESNuFoYyEL2Vwaztg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
