Replacing the "resolved" state

[domenic]

In common usage, we say "resolved" to mean "rejected or fulfilled." This is unnecessarily confusing with "resolve" as a verb with the polymorphic behavior of either fulfilling if passed a non-thenable, or assimilating and adopting if passed a thenable.

In #9 I contemplate replacing the "resolve" verb with something different. Alternately, we could replace the "resolved" state with something different.

My favorite candidate so far is "settled." I've been saying it in my head for a month now and it seems right.

[briancavalier]

Settled makes me think that immediately after being settled, I should be able know the final outcome/value. I like the word, though, so maybe I just need to let it sink in a bit.

How about: committed

For p1.resolve(p2), p1 becomes committed to the same outcome as p2, even if p2 is pending.

[domenic]

Settled makes me think that immediately after being settled, I should be able know the final outcome/value.

If "settled" means "rejected or fulfilled," this is precisely true.

For p1.resolve(p2), p1 becomes committed to the same outcome as p2, even if p2 is pending.

This is not true. If you do resolve(pending); resolve(5) for p1, then p1 becomes fulfilled with 5; it doesn't have the same outcome as pending.

[briancavalier]

If "settled" means "rejected or fulfilled," this is precisely true.

I see. Thanks for clarifying.

This is not true. If you do resolve(pending); resolve(5) for p1, then p1 becomes fulfilled with 5; it doesn't have the same outcome as pending.

I wasn't able to grok this paragraph. Could you clarify? Are you saying that if resolve is the resolve() function for p1, resolve(5) somehow should "undo" and override the prior resolve(pending)?

I'm just saying that in my perception, "settled" implies an immediate finality that resolve doesn't, whereas "committed" (again, in my perception) implies sealed fate, but not a final state.

[domenic]

Are you saying that if resolve is the resolve() function for p1, resolve(5) somehow should "undo" and override the prior resolve(pending)?

Indeed, that's the point of resolution races! Multiple producers can resolve with pending promises, but only the pending promise that becomes settled first ends up dictating the final state of the promise. Otherwise resolution races would be pretty pointless---whoever's called first just resolves immediately with a pending promise, which he settles at his leisure, thus guaranteeing that no matter what happens he always wins the race.

[domenic]

Oh dear, I appear to be completely wrong. Oops. That changes things.

[domenic]

I guess I have been thinking of this all wrong. I was talking about a name for the state "fulfilled or rejected," whereas you were talking about a name for the state "eventual fate cannot be changed."

What is the value of having a word for the latter state?

[domenic]

Wow, OK, so I've been missing something big. I still think people have been abusing "resolved" to mean "either fulfilled or rejected". (Maybe just me?) In that worldview, the problem is that deferred.resolve(pendingForever); never causes deferred.promise to become "resolved".

But if we take "resolved" to mean "either fulfilled or rejected or waiting on a pending promise," as in #18, it all makes sense. We can keep both "resolved" and "resolve". Waaaaah.

[wizardwerdna]

I think the complexity seems to be in overloading the word "state." We must be careful not to do so, since the spec now has the edict that: A promise must be in one of three states: pending, fulfilled, or rejected.

There are no more states. That's it. State seems to be defined as a static property of the promise object, a state as in a state machine with specific transition properties. As presently defined, 'resolved' is not a fourth state. What is it then? Does Promise resolution change the state, except for when it doesn't change the state? Unless we are going to define a fourth state with dynamic properties, lets abstract a bit to something defined in terms of the static "state-machine" states.

I was thinking about resolution as a "condition" of the promise, but I have warmed on the use of the word "fate," a word we have been informally using. It can be temporally defined without messing with other concepts, as Dom put it, "either fulfilled, rejected, or pending the resolution of another promise." Resolved is a fate different from pending states that have not been run through Promise Resolution. States are fates too.

So now we are distinguishing temporal predicates about promises (fates) from the static states themselves, at time t, a promise's fate is settled if it is in one of the fixed states for all time. At time t, a promise's fate is resolved if it is settled, or pending the resolution of another promise.

This terminology makes sense, and gives a formal way to describe the properties of running the Promise Resolution.

Is this at all helpful?

[domenic]

@wizardwerdna Sorry for taking so long to respond, but yes indeed, that is really helpful (and I remember thinking so when I first read your message on my phone 9 days ago ^_^). I've updated #18 with that terminology.

[briancavalier]

Thanks @wizardwerdna. I'm a big fan of the "fate" terminology as well, thanks for proposing it here. Are we good here? Any reason not to close this?

[domenic]

@briancavalier no real reason not to close it, besides that almost everything in this repo is still open :P.

[briancavalier]

LOL, ok, closing it. If we need to revisit, we can reopen.