-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
Do not cancel promise once timeout fires #9
Comments
I think these are actually two independent use cases that should be clearly separated. As such, I'd vote against a boolean flag (boolean trap?) and vote for two distinct methods similar to this:
The default should probably not cancel any promises, as this is the default promise behavior (e.g. |
Should this read as "...the promise will be cancelled once..."? As i understand it, the returned promise will be always rejected, but the 👍 for 2 functions instead of a boolean. |
Indeed, thanks for spotting, I've fixed the typo in the OP :) Other than that, thanks for the feedback! Looks like we have the same understanding.
I've toyed around with this but have yet to come up with some decent function names, so perhaps you happen to have any ideas? The original name used to be |
IMHO, the default behaviour ( To be honest, i can't think of any use cases for not cancelling a promise. Maybe go with |
Well, I guess I must have been overthinking this?! :) Admittedly, all my use cases actually also assume the canceling behavior. Thanks for chiming in, very much appreciated! I have a working prototype for this locally, but will postpone this for now, until we have a valid use case. |
Edit: This is quite intertwined with #3. I have accidentally posted some comments here, that have now been moved over instead. |
I think we agree here. I guess the confusion can be cleared up by providing some documentation (see #14). I'd like to make this ticket actionable. IMO we should focus on the main use case (as discussed above) here and close the ticket now that we agree on this. The other use case can be addressed in a separate ticket once deemed useful. |
Currently, the promise will be cancelled (edit:
rejected) once the timeout fires. This is debatable, but IMHO the name "timeout" implies that we either wait for the promise to settle within the timeout or will never care about its (possible) future result.Arguably, another use case would be "checking" whether a promise settles within a given time frame. I'd like to put this out here to see if anybody happens to have any thoughts and/or actual use cases.
Also refs clue/reactphp-block#4
The text was updated successfully, but these errors were encountered: