>From looking at the module, that was far from obvious if you ask
me. Even though the docs says just that.
I'm not sure I see how having separate methods here will give us
better typing, but maybe it does.
My opinion is that we should try to have an API that is as similar as
possible to others and if that isn't possible or desirable, we should
provide examples on how to use our API as part of the docs.
>Regarding chaining â I think youâre looking for Future.map and
>Future.flat_map. Calling map in a Future will return a new Future that will be
>fulfilled with the result of the callback provided to map. flat_map allows the
>callback to return a new Future, which will be chained with the Future
>initially returned by flat_map.
>
>Future f = do_async_stuff();
>f->flat_map (lambda (string result) { return
>do_more_async_stuff_returning_a_future(result); })->on_success (lambda (string
>final_result) { });
>f->map (lambda (string result) { return reverse (result); })->on_success
>(lambda (string final_result) { });
>
>Separating it to separate methods is good when you care about typing, but JS
>doesnât care too much about typing so they combined everything into
>âthenâ in the ES6 Promise implementation (this is my personal reflection,
>I might be wrong ;) )
>
>/Marty
>
>> On 22 May 2016, at 16:40 , Marcus Agehall (nu med K-märkt fastighet och ny
>> elcentral) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote:
>>
>> I have spent some time looking at the new stuff in Concurrent.pmod
>> that Grubba has added to 8.1. Mostly it is code relating to the
>> concept of Promises and Futures which are very popular amongst
>> JavaScript people these days.
>>
>> I have noted that there seems to be some rather striking differences
>> between how JavaScript treats promises and how Pike does it. I'm not
>> sure this is a good thing(tm) and therefore I'd like to bring this up
>> before 8.1 stabilizes.
>>
>> In Pike, we have two methods that register callback functions,
>> Future.on_success() and Future.on_failure() as opposed to JS where
>> only one method, then(), is used to register both callbacks. I don't
>> mind having two different methods, but for easier transition between
>> the two languages (i.e. for people writing both client-side and
>> server-side code) having the same API would probably help.
>>
>> A bigger problem imho is the difference in how promises are actually
>> resolved. In JavaScript, the return value of then() is always a *new*
>> promise which then allows for chaining. In Pike, we return the same
>> promise object. This means that code like
>>
>> my_promise->on_success(foo)->on_success(bar)
>>
>> in Pike would result only in a call to bar() once my_promise is
>> resolved whereas in JavaScript, foo() would be called and it's return
>> value would be the input to bar in a new promise.
>>
>> The whole creation of promises is also somewhat awkward in Pike. In
>> JS, you simply pass a callback that will do all the work and that will
>> recieve a success callback and a failure callback as arguments and off
>> you go. In Pike, I'm not sure what the best way to do it is.
>>
>> I really like the idea of having promises in Pike, but would it not be
>> much better if we tried to implement an API more similar to what the
>> JS folks are used to? At least I think so...
>>
>> Here are three links to good resources I've found regarding promises
>> in JS. I'm sure there are a ton of others as well.
>>
>> https://promisesaplus.com/
>> http://www.mattgreer.org/articles/promises-in-wicked-detail/
>> http://bluebirdjs.com/docs/api-reference.html
>
>
