> 24 maj 2016 kl. 17:25 skrev Per Hedbor () @ Pike (-) developers forum
> <10...@lyskom.lysator.liu.se>:
>
> […]
> Also, I personally belong to the "future/promises don't really add much"
> camp, but feel free to add the API. :)
>
> (In my opinion it's just another way to complicate asynchronous
> programming)
I beg to differ ;)
I think the biggest benefit is that your async programming becomes/or looks
more sequential/synchroneous which tend to be easier to follow, or in other
words less spaghetti-ish.
But, as Agehall pointed out, for that to work properly in the Pike
implementation the on_success/on_failure callbacks should be able to return a
new future object that would bubble into an evetual chained
on_success/on_failure. As the implementation is right now that’s not possible.
But there are benefits as it is implemented now nontheless. In the
Protocols.HTTP.Promise module I’ve started working on you can do stuff like:
import Protocols.HTTP;
…
Concurrent.Future f1 = Promise.get_url(url1);
Concurrent.Future f2 = Promise.get_url(url2);
Concurrent.Future f3 = Promise.get_url(url3);
// Resolve when all is done or one fails.
Concurrent.Future all = Concurrent.result(({ f1, f2, f3 });
all->on_success(lambda (array(Promise.Success) res) {
// All three request succeeded
werror(”URLS: %O\n”, res->url);
})
->on_failure(lambda (Promise.Failure res) {
werror(”The URL %O failed\n”, res->url);
});
…
Or if you’d want a callback for each individual request
array(Concurrent.Future) each = ({ f1, f2, f3 });
each->on_success(lambda (Promise.Success res) {
werror(”%O succeeded with status %O\n”, res->url, res->status);
})
->on_failure(lambda (Promise.Failure res) {
werror(”%O failed with status %O\n”, res->url, res->status);
});
…
To me it’s quite easy to follow what that code does.
Regards
-----------------------------
Pontus Östlund
Developer • Roxen AB
+46 70-662 81 69
www.roxen.com <http://www.roxen.com/> | twitter.com/roxen
<https://twitter.com/roxen>
