-
Notifications
You must be signed in to change notification settings - Fork 1
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
Draft E #6
Comments
This spec is very similar to Draft B but I think people are slightly less likely to get the check for |
This is probably a good idea. Might be nice to add |
I think the restriction of the other properties not existing seems un-necessary providing you have the boolean values to check. I didn't add I'm flexible on both those points though. Let's see if anyone else has thoughts on those two points. |
Well, remember that we're writing a specification here ;). Anything left unspecified can be used for great evil, e.g. |
Actually, I was thinking of performance implications of adding properties being potentially significant, but we don't need to worry about that as we should really return a fresh object each time. |
OK, I've added those in. I'm still yet to be convinced of the value added by an extra |
One last thing: I think we need language that states that modifying the object returned from Otherwise, I think this is great and we should push for consensus. |
Gaah, wait, I'm not an admin here, I can't edit. Anyway, I'm thinking a requirement 4, along the lines of
(note 2): implementations may, if they choose, freeze the returned object in order to make this more obvious. |
+1 |
What do we think of a |
if(promise.inspectState().isFulfilled){ versus if(promise.inspectState().state === "fulfilled"){ |
I've added requirement 4 as per @domenic's suggestion The booleans seem less prone to typos like: if(promise.inspectState().state === "fulfiled"){
//never happens
} |
@ForbesLindesay why is that typo more likely than if (promise.inspectState().isFulfiled) {
// never happens
} ? |
@kriskowal would something like this work for your Montage use case, or would the non-live object returned by |
Yeah, non-reactive state object would not fly for the Montage use-case if you wanted to use a promise as a direct controller for bindings. Bear in mind that such a system would be convenient but not necessary since it’s trivial to construct a reactive state object with https://github.com/montagejs/montage/blob/integrate-bindings/core/promise-controller.js |
Oh right, that makes sense. So this wouldn't be any better or worse than what Q already does for that use case. General comments welcome while you're here :). |
I would favor |
I guess the desire was to minimize API surface and make it easily testable if you're dealing with a promise implementation that has these features ( |
@domenic I’m not buying it from a user perspective. At the very least, |
You're always so insistent on "error" over "reason," heh ;). If anything "exception" seems better since it's not necessarily |
I think: if (promise.inspectState().isFulfiled) {
// never happens
} is a marginally less likely typo because clever auto complete/static analysis might be expected to pick that up and make suggestions, but I haven't yet seen one that attempts to fix text you put in string literals. I like |
FYI I've implemented this in legendary@0.8.0, with @ForbesLindesay remind me why we require both |
Because it could be pending, fulfilled, or rejected. To store 3 possible states you require 2 bits. I'm treating each property as a boolean (not some kind of tri-state with |
Sorry, I wasn't clear enough. Why do we require both |
There's no |
Cleaner how? You already write "Must not have a property named |
Because the normal check runs: var state = promise.inspectState();
if (state.isFulfilled) {
//do something
} Feels a lot more natural if |
I am really starting to dislike the booleans approach, favoring instead a single |
Booleans do allow for extra information, e.g. I'd like to encode whether the promise was cancelled, without having to inspect the |
I'm fine with either, I just prefer testing an object for known values, than testing for the existence/lack of existence of a property. |
Promises/A+ Extension: Synchronous Inspection
This proposal extends the Promises/A+ specification to cover synchronous inspection of a promise's fulfillment value or rejection reason.
It is not expected that all Promises/A+ implementations will include this extension. If the features of this extension are desired, you should test for them:
Motivation
TODO
Requirements: the
inspectState
methodA promise implementing this specification must have an
inspectState method
, which returns an object.isFulfilled
with a value offalse
isRejected
with a value offalse
fulfillmentValue
rejectionReason
isFulfilled
with a value oftrue
isRejected
with a value offalse
rejectionReason
isFulfilled
with a value offalse
isRejected
with a value oftrue
fulfillmentValue
Notes
undefined
, you must checkisFulfilled
andisRejected
. That is, the proper way to synchronously test for a promise being fulfilled is notif (promise.inspectState().fulfillmentValue)
or evenif (promise.inspectState().fulfillmentValue !== undefined)
, but insteadif (promise.inspectState().isFulfilled)
.The text was updated successfully, but these errors were encountered: