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.
For more options, visit https://groups.google.com/d/optout.
