Scala: Is Promise redundant?

A related question: Why do we need both Future and Promise?

If I understand the Scala Future/Promise API right, Future and Promise have a one-to-one relationship between them, and it's possible to go from a promise to its corresponding future, but not vice versa.

In the code examples that I have seen so far, Promise may be used by the (asynchronous) task implementer, but what that is returned to eventually the client is the corresponding Future to read the result from.

This makes sense, since as a task implementer, I do not want to allow the client the ability do set the task as completed, only to read its result when its completed.

So Promise is often described as essential due to being the way for the task implementer to update/write (once only) the result of the task, and Future as the way to read the result by the client.

I understand why Promise may be useful or "okay to have" as an internal implementation detail of Future.

But is it actually essential to expose Promise as a public API to the developer? As a task implementer, I can create the required Future without the Promise API, simply by Future.apply .

In the code block that I pass to Future.apply I can decide what to return as a successful result, and when to throw exceptions. This is equivalent to what I can do with Promise.

It seems to me like originally there was only something like Promise, with an additional ability to query the Promise for the completed result (value/exception) which now has been delegated to Future. And only later Future was added to the API, but for some reason Promise was kept exposed.

So my question is, is there anything essential in Promise that cannot be done by Future, or is Promise redundant?

Pay attention: I am not asking if Promise and Future are two different concepts which justify different entities. I am asking if Promise provides a practical ability that cannot be achieved by Future alone.


Let's give this a try...

Promise allow completing Future s based on external events/triggers.

Imagine you are using a service to which you post orders, those orders need a long time to execute so you will only get feedback (the result of the execution) much later.

How would you handle that with Future only? You would need to constantly poll for the result (from the Future.apply body).

Using a Promise , you could wait for the service to trigger a callback once done. When that trigger happens, you can complete the Future using the Promise . You complete the Future from outside of the Future.apply body, that's what I meant above by external events/trigger.

In other words, a Promise is a safe way to complete a Future from outside, and there's no other way to do it: the Promise API is essential.


You can pass a Promise to some other part of code and allow it to complete the Future when and how it wants.

As a task implementer, I can create the required Future without the Promise API, simply by Future.apply.

You may just want to create Future s. But other people need to write functions which work with Future s, and they need Promise .

链接地址: http://www.djcxy.com/p/55434.html

上一篇: 初始化Promise(Scala)

下一篇: 斯卡拉:承诺是多余的?