Replies: 3 comments
-
In my opinion, adding a I can also imagine it would be confusing for newcomers, and it doesn't really fit in the current API design in which most method have been converted into functions. Although, one could always implement the Future.prototype.then = function (f, g) { return Future.promise (this).then (f, g); } |
Beta Was this translation helpful? Give feedback.
-
I agree with you that it will be confusing for newcomers. The idea comes to my mind building a lib to work with the DB that lazy return Fluture futures. My object implement a fork method, like Fluture operator. But there is no a standard interface between Fluture (F.lock()()()), my lib (myobject.fork()()) and standard promises (promise.then()). So I have to discriminate at consume time how to consume the 3 different kind of objects to mix results. Reasoning about native async/await support, probably a .then method would be a nice interface to implement in any library that can be consumed as promises. But as you suggest I can add it to Futures myself. So I'm ok with that solution for my project :) |
Beta Was this translation helpful? Give feedback.
-
See also #35 |
Beta Was this translation helpful? Give feedback.
-
Why not adding a "then" method to convert into Promise to make a Fluture instance consumable by await? Could spare some line of code when integrating with other libs.
this way:
const f = Future.resolve(1)
async function myApp() {
...
const r2 = await f
...
}
Instead of
const f = Future.resolve(1)
async function myApp() {
...
const r2 = await Future.promise(f)
...
}
That may be useful in an async function because we dont have to discriminate between futures and promises
Beta Was this translation helpful? Give feedback.
All reactions