-
-
Notifications
You must be signed in to change notification settings - Fork 146
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
Implement Interop\Async\Promise #76
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.
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