-
Notifications
You must be signed in to change notification settings - Fork 165
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
Clarify when onFulfilled
/onRejected
must *not* be called
#129
Comments
Interesting. I think a language change is reasonable. I prefer your first suggestion of the explicit bullets. |
I'm curious whether anyone can make an implementation that follows the existing spec/passes the existing tests, but still disobeys these bullets? |
@domenic I actually don't believe it's possible. The problem, though, is that the current spec simply may not be clear enough, and may cause confusion, which seems to be what happened in promises-aplus/promises-tests#36 |
Hmmm, what about a promise that remains pending forever? Seems the spec allows an implementation to call either |
Nice catch, agreed it's a hole. Kind of a symptom of our requirements-based (as opposed to algorithm-based) spec, but what can you do. |
…t not be called before promise is fulfilled or rejected.
Ok, I took a shot at it in #130. I think it's possible to specify what we want by simply changing two bullets, rather than adding more. Let me know if you think this captures what we want and also doesn't open any new holes :) |
…t not be called before promise is fulfilled or rejected.
Fixes #129 by prohibiting `onFulfilled` and `onRejected` from being called before the promise is respectively fulfilled or rejected. An example of behavior the current spec allows would be for an implementation to call `onFulfilled` or `onRejected` once, even on a promise that remains pending forever.
See promises-aplus/promises-tests#36. Copied from my comment.
It seems there is nothing that explicitly prevents an implementation from calling
onRejected
between the instant a promise is fulfilled and the instantonFulfilled
is called, which then makes section 3.2.2 into a contradiction:onFulfilled
must be called (3.2.2.1), but also must not be (3.2.2.3)!It also seems that there's nothing that explicitly prevents an implementation from calling either
onFulfilled
oronRejected
while a promise is pending.These things are certainly implied, and if an implementation chose to do them, it seems that would make it impossible (afaict) to satisfy the other requirements of the spec (specifically 3.2.2, 3.2.3 and 3.2.5).
Perhaps we need to add a few explicit statements to clarify? Something like:
onFulfilled
andonRejected
must not be called while promise is pending.onFulfilled
must not be called after promise is rejected.onRejected
must not be called after promise is fulfilled.Another alternative might be to add "only" to existing requirements:
What do others think? Do we have some holes here we need to patch, or are the current implications strong/obvious enough?
The text was updated successfully, but these errors were encountered: