You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 22, 2025. It is now read-only.
Q.allResolved is misnamed (due to our new meaning of "resolved" over in promises-aplus/constructor-spec#18) and relies on the clunky synchronous inspection API. I propose Q.allSettled, which always fulfills with an array of the snapshot objects from #256.
Trivial question w.r.t naming: if the deferred.reject() has state "rejected", then shouldn't deferred.resolve() have state "resolved" and not "fulfilled"? (assuming I am reading this all correctly).
deferred.reject(reason) is really a synonym for deferred.resolve(Q.reject(reason)). The argument of resolve can be a promise in any state—or—a value which gets implicitly boxed as a fulfilled promise for that value (Q(value)).
So, resolve can actually transition a deferred to any state, pending (through resolving to a deferred promise), rejected (through resolving to a rejected promise), or fulfilled (through resolving to a fulfilled promise, or simply to a value).
Q.allResolved
is misnamed (due to our new meaning of "resolved" over in promises-aplus/constructor-spec#18) and relies on the clunky synchronous inspection API. I proposeQ.allSettled
, which always fulfills with an array of the snapshot objects from #256.Usage example:
I am proposing something similar for when.js over in cujojs/when#119 (comment) which is getting somewhat-positive reception.
The text was updated successfully, but these errors were encountered: