Promise Resolution Procedure

[wizardwerdna]

Is this really a Promise Resolution Procedure, we are "running"? It seems to me that we are trying to in some sense link a promise to the fate of a value v. In the known promise context, we are linking the fate of the returned promise of a then to the fate of the returned promise from a callback. In the other contexts, we are trying to emulate that through assimilation.

Perhaps (and I KNOW I am coming to this late in the game) we might consider calling this a Promise Linkage Procedure, denoting it as [[Link]](promise, v)?

Thanks very much for all you have done.

[briancavalier]

Hey @wizardwerdna! Good to see you over here in Promises/A+ land :)

The term "resolve" is well-grounded in promise history, and is used in many existing promise implementations. Unfortunately, there is also some confusion around the word, due at least in part to many implementations using the word "resolve" when they actually mean "fulfill". So, we did debate a good deal (see #9 and #16) about trying to find a new word. In the end, we decided simply to use "resolve", attempt to clarify its meaning, and educate about it. We felt this was better than introducing new words/concepts (like "assimilate") people need to learn when discovering promises.

[domenic]

Indeed, and I think we have actually clarified resolve from how it's previously used. Sometimes the "resolved" adjective was used to mean "either fulfilled or rejected," which doesn't match with what the resolve verb does. Instead, we clarified it to mean "either fulfilled, rejected, or pending because the promise has adopted the state of another pending promise"---which is exactly the result of the "resolve" verb. See promises-aplus/constructor-spec#18.

But yes, [[Resolve]] fits very well with e.g. Q.defer().resolve, when.defer().resolve, Q.resolve, RSVP.resolve, and the conventional name of the arguments to the resolvers passed to Q, RSVP, and when's promise constructors.