-
-
Notifications
You must be signed in to change notification settings - Fork 150
Implement Interop\Async\Promise #76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| UnhandledRejectionException::nullOrResolve($reason), | ||
| null | ||
| ); | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both $onResolved calls should be wrapped with try / catch blocks and be forwarded to the error handler, currently the one of Loop, once the PR is merged, to the promise error handler: async-interop/promise#19
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but since we're requiring ^0.2.0 and do not require async-interop/event-loop there is no other way at the moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just fixed my patch, so we can merge the PR soon and have a new release hopefully.
| $onResolved( | ||
| UnhandledRejectionException::nullOrResolve($this->reason), | ||
| null | ||
| ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, needs a try / catch then.
| if ($promiseOrValue instanceof AsyncInteropPromise) { | ||
| return new Promise(function ($resolve, $reject) use ($promiseOrValue) { | ||
| $promiseOrValue->when(function ($reason = null, $value = null) use ($resolve, $reject) { | ||
| $reject($reason ? $reason : $value); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are both null here fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't found anything in the specification which defines how the callbacks must be invoked and if none, only $reason or both arguments are required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The specification states:
Any implementation MUST at least provide these two parameters.
But what I was rather asking here is whether $reject is fine with null being passed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we allow rejection without a reason:
https://github.com/reactphp/promise/blob/2.x/src/functions.php#L26
https://github.com/reactphp/promise/blob/2.x/src/RejectedPromise.php#L9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just wasn't sure because of UnhandledRejectionException::nullOrResolve. RejectedPromise seems to miss a check for AsyncInteropPromise in __construct btw.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just wasn't sure because of UnhandledRejectionException::nullOrResolve.
nullOrResolve was actually wrong. In case of rejection without a reason, it would call the when() callbacks with null as first argument signalling success instead of failure. This is fixed in 8073b04.
RejectedPromise seems to miss a check for AsyncInteropPromise in __construct btw.
Good catch, fixed in 8c68ff6
| } | ||
|
|
||
| /** | ||
| * Implementations MAY fail upon resolution with an AsyncInteropPromise, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they MAY fail, that means we can't rely on it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment is copied over from @bwoebi's https://github.com/async-interop/awaitable-test/blob/master/src/Test.php#L184 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, right. fail in the sense of being rejected.
|
Superseded by #78 |
Would be great if anyone from the async-interop team (@trowski, @kelunik, @bwoebi) could have a look at the implementation.
Closes #64