tag:blogger.com,1999:blog-9112560338291574360.post5430503859027025057..comments2024-03-02T08:28:27.119+00:00Comments on LeoNerd's programming thoughts: Futures advent day 2LeoNerdhttp://www.blogger.com/profile/06161372680495361467noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-9112560338291574360.post-17549828481554741752014-11-07T22:24:25.636+00:002014-11-07T22:24:25.636+00:00Thanks! The Net::Async::HTTP solution is perfect....Thanks! The Net::Async::HTTP solution is perfect.Bill Rupperthttp://www.billruppert.comnoreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-91848654819412148242014-11-07T15:44:18.569+00:002014-11-07T15:44:18.569+00:00I should probably add that nobody ought to rely on...I should probably add that nobody ought to rely on this latter implementation as it doesn't return real HTTP::Response objects, only the plain content string. More work would be required to make a real compatible version.LeoNerdhttps://www.blogger.com/profile/06161372680495361467noreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-23271540656772846992014-11-07T15:43:13.758+00:002014-11-07T15:43:13.758+00:00Well, obviously the simplest asynchronous Future-b...Well, obviously the simplest asynchronous Future-based HTTP client is the Net::Async::HTTP one, because that already returns Futures:<br /><br />$loop->add( my $http = Net:Async::HTTP->new );<br /><br />sub HTTP_GET<br />{<br /> my ($url) = @_;<br /> return $http->GET($url);<br />}<br /><br />For other event systems, similar concepts will likely be applicable, perhaps via the various Future wrappings, such as for AnyEvent. This one's a little more awkward mostly due to the glue between AnyEvent::HTTP and Future:<br /><br />use AnyEvent::Future qw( as_future_cb );<br />use AnyEvent::HTTP qw( http_get );<br /><br />sub HTTP_GET<br />{<br /> my ($url) = @_;<br /> return as_future_cb {<br /> my ( $done, $fail ) = @_;<br /><br /> return http_get $url, sub {<br /> my ( $data, $headers ) = @_;<br /> defined $data ? $done->( $data ) : $fail->( $headers->{Reason} );<br /> };<br /> };<br />}LeoNerdhttps://www.blogger.com/profile/06161372680495361467noreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-10162160136948222702014-11-06T16:40:01.061+00:002014-11-06T16:40:01.061+00:00Great! How about a simple asynchronous case?Great! How about a simple asynchronous case?Bill Rupperthttp://www.billruppert.comnoreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-43724571793911852332014-11-06T16:15:44.282+00:002014-11-06T16:15:44.282+00:00Ah sure. For a simple synchronous use-case, you co...Ah sure. For a simple synchronous use-case, you could just wrap the LWP::UserAgent HTTP function in a Future-returning function that just returned an immediate Future. For example:<br /><br />sub HTTP_GET<br />{<br /> my ($url) = @_;<br /> my $response = $ua->get($url);<br /> return Future->done($response);<br />}<br /><br />This obviously isn't going to do anything asynchronous, but it will still behave like any other Future-returning HTTP get function, allowing it to play along with any other Future-using code.LeoNerdhttps://www.blogger.com/profile/06161372680495361467noreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-21361150154884796752014-11-06T15:09:46.021+00:002014-11-06T15:09:46.021+00:00I just watched your YAPC::EU 2014 and was very imp...I just watched your YAPC::EU 2014 and was very impressed. I would like to work my way through the advent calendar to get up to speed. I'm trying to get them to run. <br /><br />However, I'm don't know much about async (hence the appeal), I just use LWP::UserAgent. So I'm afraid the presumption of a GET_HTTP function "wrapped in the obvious manner" is over my head! Can you point to such a function? Bill Rupperthttp://www.billruppert.comnoreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-13134144222040572082013-12-02T12:19:03.573+00:002013-12-02T12:19:03.573+00:00Essentially, yes. The basic concept was independen...Essentially, yes. The basic concept was independently created across a number of languages, and it turns out that two sets of terminology were created to name them.<br /><br />There tends to be a slight preference that functional languages prefer the word "Future", as compared imperative preferring "Promise". As such, the two styles sometimes have minor different semantics. Though that's only a convention, not a hard rule. C++ for example creates objects in pairs, in a way a little similar to a pipe() call, in that it has one object that the supplier will put the result into, and a different object that the consumer will read the result from. It calls these two the Future and the Promise.LeoNerdhttps://www.blogger.com/profile/06161372680495361467noreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-72325897072922897472013-12-02T11:08:28.536+00:002013-12-02T11:08:28.536+00:00Are future's basically a promise object? (perh...Are future's basically a promise object? (perhaps this'll be covered)Anonymoushttps://www.blogger.com/profile/08185254298048097278noreply@blogger.com