Replacing the "resolve" verb

[domenic]

Here is our terminology problem with current libraries:

1. We have fulfilled, rejected, and pending as three mutually-exclusive states. Everyone is reasonably happy with those names.
2. We want a name for the operation operation(x) coupled to promise p where if x is a non-promise value, p becomes fulfilled with x, and if x is a promise, p adopts its state, either immediately or eventually. Currently this is called "resolve."
3. We want a way of talking about the two "not pending" states as a single entity. Currently this is called "resolved."
4. The problem is that if you "resolve" a promise as per 2, it does not become "resolved" as per 3.

Let's use this thread to think of replacements for the verb in 2, assuming that we keep the state name as of 3.

Ideas so far:

• "designate": designate(x) causes p to designate whatever x designates.
• "adopt": adopt(x) causes p to adopt x's (possibly eventual) state
• "become": become(x) causes p to become x. (Problem: cannot use transitively, i.e. "become p with x" is awkward.)
• "yield": yield(x) causes p to yield to x's value. (Confusing with upcoming yield keyword.)

No ideas that jump out at me so far... anyone got anything better?

[briancavalier]

Good summary, thanks! Seems like we need a word which is not "resolve" that means "seal the fate of p". Or we have to extend the definition of "resolved" to mean "a promise whose fate has been sealed, and may or may not have been met"--that seems like it may confuse people more.

In another thread somewhere, I proposed "assume": assume(x) causes p to assume x's state/value. Very similar to adopt.

[domenic]

New favorite via MarkM: "reveal". It's especially nice as a counterpart to "reject" and makes a lot of sense when used in this type of context:

var p = new Promise(function (reveal, reject) {
  if (Math.random() > 0.5) {
    reject(new Error("the universe doesn't like you today"));
  }
  reveal(5);
});

or playing off ideas from previous threads, maybe

var p = new Promise(function (resolver) {
  if (Math.random() > 0.5) {
    resolver.reject(new Error("the universe doesn't like you today"));
  }
  resolver.reveal(5);
});

although this keeps the "resolver" noun which has only an indirect connection to the "resolved" state. Alternately

var p = new Promise(function (reveal) {
  if (Math.random() > 0.5) {
    reveal.reject(new Error("the universe doesn't like you today"));
  }
  reveal(5);
});

[briancavalier]

I agree "reveal" is a very nice word, and a nice counterpart to "reject"--even the same number of letters. I'm not sure it works well in this case tho: reveal(pending). I'll let it sink in a bit more ...

[domenic]

Another one from MarkM: "settle". settle(pending) settles the state of p to be whatever pending ends up being; settle(val) settles the state of p to be fulfilled with val.

[juandopazo]

Microsoft is using complete

[lsmith]

FWIW, I have no qualms with resolve, despite the semantic weirdness. Depending on the outcome of #7, this may be moot, no? Well, maybe moot in practice, but substantive insofar as documentation uses method names that suggest a purpose and will be adopted ala cut/paste. Still, I'm not offended by the de facto use of resolve, considering my stance on #7.

[domenic]

@lsmith I don't think it's moot unless we abolish the use of "resolved" as a state encompassing "fulfilled or rejected."

There could be another issue for replacing the adjective as opposed to the verb, if people think that would be fruitful.

[lsmith]

@domenic Just a gut reaction here, but I'd say addressing the adjective would be a better approach. The promise is either pending or it's not. There are plenty of options here: "sealed", "completed", "active/inactive", "open/closed". Bummer that "unpending" isn't a word.

That said, I'm still fine with the imperfection of "resolved" as well.

[briancavalier]

When I posted above about changing the meaning of "resolved", I thought it would be more confusing to people, but hearing you guys talk about it makes me think it may be the right way to go. We could simply redefine "resolved" (or maybe we'd be formally defining it in the first place) to mean what we want it to mean.

Are you thinking that "pending" and "resolved" are mutually exclusive? i.e. if I have a promise, p1, that has been "resolved" with another pending promise, do we say that p1 is still pending? Or do we say that p1 is "resolved", but not yet fulfilled or rejected? The latter seems right to me.

This has implications with promises-aplus/promises-spec#61 as well, since the proposal there was to define isPending(promise) as !isFulfilled(promise) && !isRejected(promise). Depending on the relationship between pending, resolved, fulfilled, and rejected, that may no longer be correct. I think it's still possible to implement isPending(promise) in terms of mostResolved (nearer/nearest/whatev), though. Although, again, we're still debating whether sync value/state extraction is even something we should specify.

[briancavalier]

Back on the verb naming, just thought of: "commit"

[skaegi]

On the adjective front, we use "completed". Other suggestions... "finished", "done", and "decided".

resolve() is the verb used in the Deferred implementation of JQuery, Dojo, Q, Orion and probably others. I'm not saying it's right however keep in mind that in many cases those libraries will likely have to keep that function name to avoid breaking compatibility.

For the verb, I'm curious why fulfill() hasn't been suggested as that seems an obvious candidate or perhaps that word is overloaded too

[domenic]

@skaegi there's a difference between "resolve" as the promise community uses it, "resolve" as jQuery uses it, and "fulfill" as the promise community uses it:

• promise-community "resolve": the operation(x) from the original post.
• jQuery "resolve" and promise-community "fulfill": fulfills the promise with the given value; no special casing for when it's given promises

[skaegi]

Thanks @domenic -- suddenly your initial post makes much more sense.
In that case I like @briancavalier's suggestion -- assume but also like the continuity of a "re" word. Perhaps resume or replace but maybe that's a stretch.

[briancavalier]

Another one that just popped into my head: "follow". promise2.follow(promise1) - promise2 will now follow the state of promise1

[ForbesLindesay]

I like follow I think it's the best so far. I'm not that adverse to resolve though. It could just be that I'm used to it. Ideally we'd introduce some new people to promises and see how they reacted to different verbs.

[domenic]

FWIW I'm coming around to the replace-the-adjective approach. A lot of this depends on how we resolve the reject vs. polymorphicReject question though.

[domenic]

What about accept?

Doesn't seem great from an English standpoint ("I accept my promise with this other promise", "I accept my promise with the value 5"), but is an interesting counterpart to reject.

[briancavalier]

Ah, accept is a nice word. One concern: If accept is polymorphic and reject is not, I wonder if accept is too parallel of a word.

[briancavalier]

As per #16, another suggestion: commit