You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document describes a few design considerations, for the main specification, refer to [the README document](README.md).
4
4
5
-
## Recommended usage of Awaitable
5
+
## Recommended usage of Promises
6
6
7
7
We are explicitly _not_ providing a chainable method, thus we are also not recommending to chain them, but rather to use coroutines in form of generators inside application code.
8
8
@@ -12,16 +12,14 @@ Coroutines solve the problem of the so-called callback hell very nicely and also
12
12
13
13
The specification proposes `when()` in order to only expose the most primitive common denominatior needed for interoperability, which is a simple callable to be executed after the resolution.
14
14
15
-
If implementations wish to adhere to e.g. [Promises/A+ from Javascript](https://promisesaplus.com) (which had been implemented in many PHP Promise libraries at the time of writing this specification) or implement any other methods, they still may do so; `when()` however is the fundamental interoperable primitive every `Awaitable` is guaranteed to have.
15
+
If implementations wish to adhere to e.g. [Promises/A+ from Javascript](https://promisesaplus.com) (which had been implemented in many PHP Promise libraries at the time of writing this specification) or implement any other methods, they still may do so; `when()` however is the fundamental interoperable primitive every `Promise` is guaranteed to have.
16
16
17
-
Additionally, coroutines do not use the returned `Promise` of a `then` callback, but returning a `Promise` is required by Promises/A+. Thus there's a lot of useless object creations when using Awaitables the recommended way, which isn't cheap and adds up. This conflicts with the goal of being as lightweight as possible.
17
+
Additionally, coroutines do not use the returned `Promise` of a `then` callback, but returning a `Promise` is required by Promises/A+. Thus there's a lot of useless object creations when using Promises the recommended way, which isn't cheap and adds up. This conflicts with the goal of being as lightweight as possible.
18
18
19
19
## Naming
20
20
21
-
As we are not using a thenable, which is sometimes associated with the word `Promise`, we decided against using `Promise`.
21
+
Even though we are not using a thenable, `Promise` is a more recognizable and accepted name for future value placeholders.
22
22
23
-
Thus, `Awaitable` was a logical choice, with [HHVM already having it](https://docs.hhvm.com/hack/reference/interface/HH.Awaitable/) and PHP possibly also being some day extended to natively support an `await` keyword.
23
+
## Creation of Promises
24
24
25
-
## Creation of Awaitables
26
-
27
-
Awaitable creation and managing is out of scope of this specification, as managing never shall cross library boundaries and thus does not need to be interoperable at all; each library shall resolve the Awaitable it created itself.
25
+
Promise creation and managing is out of scope of this specification, as managing never shall cross library boundaries and thus does not need to be interoperable at all; each library shall resolve the Promise it created itself.
Copy file name to clipboardExpand all lines: README.md
+14-14Lines changed: 14 additions & 14 deletions
Original file line number
Diff line number
Diff line change
@@ -1,31 +1,31 @@
1
-
# Awaitable
1
+
# Promise
2
2
3
3
The purpose of this proposal is to provide a common interface for simple placeholder objects returned from async operations. This will allow libraries and components from different vendors to create coroutines regardless of the used placeholder implementation. This proposal is not designed to replace promise implementations that may be chained. Instead, this interface may be extended by promise implementations.
4
4
5
5
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
6
6
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
7
7
interpreted as described in [RFC 2119][].
8
8
9
-
An `Awaitable` represents the eventual result of an asynchronous operation. Interaction with an `Awaitable` happens through its `when` method, which registers a callback to receive either an `Awaitable`'s eventual value or the reason why the `Awaitable` has failed.
9
+
A `Promise` represents the eventual result of an asynchronous operation. Interaction with a `Promise` happens through its `when` method, which registers a callback to receive either a `Promise`'s eventual value or the reason why the `Promise` has failed.
10
10
11
-
`Awaitable` is the fundamental primitive in asynchronous programming. It should be as lightweight as possible, as any cost adds up significantly.
11
+
`Promise` is the fundamental primitive in asynchronous programming. It should be as lightweight as possible, as any cost adds up significantly.
12
12
13
13
This specification defines the absolute minimums for interoperable coroutines, which can be implemented in PHP using generators.
14
14
15
-
This specification does not deal with how to create, succeed or fail `Awaitable`s, as only the consumption of `Awaitable`s is required to be interoperable.
15
+
This specification does not deal with how to create, succeed or fail `Promise`s, as only the consumption of `Promise`s is required to be interoperable.
16
16
17
17
For further design explanations and notes, please refer to [the meta document](META.md).
18
18
19
19
## Terminology
20
20
21
-
1._Awaitable_ is an object implementing `Interop\Async\Awaitable` and conforming to this specification.
22
-
2._Value_ is any legal PHP value (including `null`), except an instance of `Interop\Async\Awaitable`.
21
+
1._Promise_ is an object implementing `Interop\Async\Promise` and conforming to this specification.
22
+
2._Value_ is any legal PHP value (including `null`), except an instance of `Interop\Async\Promise`.
23
23
3._Error_ is any value that can be thrown using the `throw` statement.
24
-
4._Reason_ is an error indicating why an `Awaitable` has failed.
24
+
4._Reason_ is an error indicating why a `Promise` has failed.
25
25
26
26
## States
27
27
28
-
An `Awaitable` MUST be in one of three states: `pending`, `succeeded`, `failed`.
28
+
A `Promise` MUST be in one of three states: `pending`, `succeeded`, `failed`.
29
29
30
30
| A promise in … state | |
31
31
|----------------------|--------|
@@ -37,7 +37,7 @@ An `Awaitable` MUST be in one of three states: `pending`, `succeeded`, `failed`.
37
37
38
38
## Consumption
39
39
40
-
An `Awaitable` MUST implement `Interop\Async\Awaitable` and thus provide a `when` method to access its current or eventual value or reason.
40
+
A `Promise` MUST implement `Interop\Async\Promise` and thus provide a `when` method to access its current or eventual value or reason.
41
41
42
42
```php
43
43
<?php
@@ -47,10 +47,10 @@ namespace Interop\Async;
47
47
/**
48
48
* Representation of a the future value of an asynchronous operation.
49
49
*/
50
-
interface Awaitable
50
+
interface Promise
51
51
{
52
52
/**
53
-
* Registers a callback to be invoked when the awaitable is resolved.
53
+
* Registers a callback to be invoked when the promise is resolved.
@@ -68,13 +68,13 @@ The `when` method MUST accept at least one argument:
68
68
function($error, $value) { /* ... */ }
69
69
```
70
70
71
-
Any implementation MUST at least provide these two parameters. The implementation MAY extend the `Awaitable` interface with additional parameters passed to the callback. Further arguments to `when` MUST have default values, so `when` can always be called with only one argument. `when` MAY NOT return a value. `when` MUST NOT throw exceptions bubbling up from a callback invocation.
71
+
Any implementation MUST at least provide these two parameters. The implementation MAY extend the `Promise` interface with additional parameters passed to the callback. Further arguments to `when` MUST have default values, so `when` can always be called with only one argument. `when` MAY NOT return a value. `when` MUST NOT throw exceptions bubbling up from a callback invocation.
72
72
73
73
> **NOTE:** The signature doesn't specify a type for `$error`. This is due to the new `Throwable` interface introduced in PHP 7. As this specification is PHP 5 compatible, we can use neither `Throwable` nor `Exception`.
74
74
75
-
All registered callbacks MUST be executed in the order they were registered. If one of the callbacks throws an `Exception` or `Throwable`, it MUST be rethrown in a callable passed to `Loop::defer` so `Loop::onError` can be properly invoked by the loop. `Loop` refers to the [global event loop accessor](https://github.com/async-interop/event-loop/blob/master/src/Loop.php). The `Awaitable` implementation MUST then continue to call the remaining callbacks with the original parameters.
75
+
All registered callbacks MUST be executed in the order they were registered. If one of the callbacks throws an `Exception` or `Throwable`, it MUST be rethrown in a callable passed to `Loop::defer` so `Loop::onError` can be properly invoked by the loop. `Loop` refers to the [global event loop accessor](https://github.com/async-interop/event-loop/blob/master/src/Loop.php). The `Promise` implementation MUST then continue to call the remaining callbacks with the original parameters.
76
76
77
-
If an `Awaitable` is resolved with another `Awaitable`, the `Awaitable` MUST keep in pending state until the passed `Awaitable` is resolved. Thus, the value of an `Awaitable` can never be an `Awaitable`.
77
+
If a `Promise` is resolved with another `Promise`, the `Promise` MUST keep in pending state until the passed `Promise` is resolved. Thus, the value of a `Promise` can never be a `Promise`.
0 commit comments