Why not thenables? about fluture

[Avaq]

See also #35

[dicearr]

I am probably misunderstanding you but, a Future can be easily turned into a Promise by using Future.promise.

---

In my opinion, adding a .then method to Futures would be misleading. In case it simply converts the Future into a Promise, could we say that Futures are Thenables? Once you call .then you've already lost the Future. And if we want to keep them as Thenable Futures I imagine it would require a non-straight forward .then implementation that returns a Future. And I don't really know how things like eagerness/laziness and cancellations, would behave in that case. I don't think is worth the burden. But I might be completely wrong here.

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 .then method in user-land.

 Future.prototype.then = function (f, g) { return Future.promise (this).then (f, g); }

[FbN]

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 :)