Editorial: create EnqueuePromiseReactions abstract operation.
#592
Conversation
This unobservable spec refactor allows the `Promise#finally` proposal to make a much smaller change, so it can reuse some of the logic in PerformPromiseThen. (following up on tc39#584)
| <h1>EnqueuePromiseReactions ( _promise_, _fulfillReaction_, _rejectReaction_, _resultCapability_ )</h1> | ||
| <p>The abstract operation EnqueuePromiseReactions enqueues PromiseJobs with the provided PromiseReaction records on _promise_. The result is _resultCapability_'s promise.</p> | ||
| <emu-alg> | ||
| 1. Assert: IsPromise(_promise_) is *true*. |
There was a problem hiding this comment.
Do we really need type-testing assertions for all arguments? :-/
There was a problem hiding this comment.
I think they're both necessary in the algorithm, and unobservably skippable in all implementations.
There was a problem hiding this comment.
They're definitely not necessary; nothing will change depending on their presence or absence. The question is whether they're helpful or annoying/distracting, and I claim the latter. In general abstract ops don't do type assertions on their arguments, except in cases where it could be potentially unclear (e.g. what type of completion record they will end up getting). This has only one call site so it seems super-unnecessary.
There was a problem hiding this comment.
Probably #545 will help this :-P
|
Sympathetic to making the finally spec easier to write but I don't think this will help your spec text be much more understandable and it doesn't stand on its own without P#finally. Let's just include this refactoring with the P#finally proposal! |
This unobservable spec refactor allows the
Promise#finallyproposal to make a much smaller change, so it can reuse some of the logic in PerformPromiseThen.(following up on #584)