是否“解决”始终意味着与“履行”不同的东西？ [英] Does "resolve" consistently mean something distinct from "fulfill"?

问题描述

（相关但不完全相同： JS Promises：Fulfill vs Resolve ）

(Related but not quite the same: JS Promises: Fulfill vs Resolve)

我一直试图围绕Javascript承诺，我正在努力解决 resolve 和的基本概念已解决，与履行和已履行。我已阅读了几篇介绍，例如 Jake Archibald's ，以及浏览一些 相关 specs 。

I've been trying to wrap my head around Javascript promises, and I'm struggling with the basic notions of resolve and resolved, vs. fulfill and fulfilled. I have read several introductions, such as Jake Archibald's, as well as browsing some relevant specs.

在状态和命运（不是官方规范，但引用为其中一位规范作者撰写的权威文档）， 履行是一种状态，而已解决是一种命运（无论是什么 - 但它们明显不同）：

In States and Fates (not quite an official spec, but referenced as an authoritative document written by one of the spec authors), fulfilled is a state while resolved is a "fate" (whatever that is -- but they're clearly distinct):

Promises有三种可能的相互不同用户状态：已履行，
被拒，等待。

Promises have three possible mutually exclusive states: fulfilled, rejected, and pending.

• 承诺已履行如果 promise.then（f）将尽快拨打f
  。

• A promise is fulfilled if promise.then(f) will call f "as soon as possible."

和

如果尝试<<承诺已解决强>解决或拒绝它没有效果，
即承诺已被锁定以跟随另一个
承诺，或已已完成或已拒绝

A promise is resolved if trying to resolve or reject it has no effect, i.e. the promise has been "locked in" to either follow another promise, or has been fulfilled or rejected

特别是，已解决包含两者已完成且已拒绝（已锁定在中）。 拒绝的相反（或直接对应的功能）是履行，而不是解决; 解决 包含 拒绝作为其可能性之一。

In particular, resolved encompasses both fulfilled and rejected (and locked in). The "opposite" (or directly corresponding function) to reject is fulfill, not resolve; resolve includes reject as one of its possibilities.

然而 spec 指的是<$ c $的第一个参数c> then（）方法（或其相应的抽象概念）使用履行和解决：

Yet the spec refers to the first argument to the then() method (or its corresponding abstract concepts) using both fulfill and resolve:

25.4：承诺p 已履行如果p.then（ f ， r）将立即将一个Job排入队列以调用函数f。

25.4: A promise p is fulfilled if p.then(f, r) will immediately enqueue a Job to call the function f.

25.4.1.1： [[解析]]一个函数对象用于解析给定的promise对象的函数。

25.4.1.1: [[Resolve]] A function object The function that is used to resolve the given promise object.

25.4.1.3：将解决的[[Promise]]内部插槽设置为promise。
将解决的[[AlreadyResolved]]内部插槽设置为alreadyResolved。 [然后紧接着，拒绝以完全相应的方式使用。]

25.4.1.3: Set the [[Promise]] internal slot of resolve to promise. Set the [[AlreadyResolved]] internal slot of resolve to alreadyResolved. [Then immediately after, reject is used in an exactly corresponding way.]

25.4.5.3：Promise.prototype.then（ onFulfilled ，onRejected）

25.4.5.3: Promise.prototype.then ( onFulfilled , onRejected )

也许其中最重要的是

25.4.4.5承诺。解决（x）

MDN 描述如下：

Promise.resolve（value）方法返回一个使用给定值解析的Promise对象。如果该值是一个可设置的（即具有then方法），则返回的promise将跟随那个可能的，采用其最终状态;否则返回的承诺将履行，并带有值。

The Promise.resolve(value) method returns a Promise object that is resolved with the given value. If the value is a thenable (i.e. has a "then" method), the returned promise will "follow" that thenable, adopting its eventual state; otherwise the returned promise will be fulfilled with the value.

没有提及 Promise.resolve（）有可能拒绝的方法。此外，还有 Promise.reject（）方法，但没有 Promise.fulfill（）方法。所以在这里，拒绝的对应部分是解决，而不是履行。

There is no mention of the Promise.resolve() method having the potential to reject. Furthermore, there is a Promise.reject() method, but no Promise.fulfill() method. So here, the counterpart to reject is resolve, instead of fulfill.

当然，命运一词已解决与方法（或动词） resolve 之间可能无法保证相关性。但是，当 resolve（）将承诺置于特定的履行状态时，这将是（是？）真的误导和混淆em>已完成和已解决经过精心定义，具有不同的含义。

Granted, there might be no guaranteed correlation between the "fate" term resolved, and the method (or verb) resolve. But it would be (is?) really misleading and confusing to have resolve() put a promise into a specifically fulfilled state, when the terms fulfilled and resolved have carefully been defined to have distinct meanings.

这就是发生在这里的事情......右手不知道左手在做什么，我们最后得到的文件应该是以不一致的方式使用术语的运动的指路灯？或者是否有我遗漏的内容， resolve 实际上是一个比履行更合适的术语 resolve（）方法吗？

Is that what has happened here... the right hand didn't know what the left hand was doing, and we ended up with the documents that are supposed to be the guiding lights of the movement using terms in inconsistent ways? Or is there something I'm missing, and resolve is actually a more appropriate term than fulfill for what the resolve() method does?

我并不是说对文档作者持批评态度。我理解，对于广泛分布的群体而言，历史上很难让所有文件在所有文档中得到一致使用。我在这里挖掘这些文档的术语和措辞的目的是准确理解这些术语 - 其中包括了解完成和解决这些术语的准确性限制可以真正区分。 Jake Archibald承认他有时会得到条款混淆了。对于像我这样试图理解术语的新手来说，这是一个非常有用的录取！杰克，谢谢你的弱势。 :-)我提出这个问题的目的是找出这些术语 可靠的定义或用法？或者我应该得出结论 resolve 有时特别用于表示履行，有时履行/拒绝/锁定，即使在最权威的文档中也是如此？

I don't mean to come across as critical of the document authors. I understand how, with a widely-distributed group, over history, it's difficult to get all the terms to be used consistently across all documents. My purpose here, in digging into the terminology and phrasing of these documents, is to understand the terms accurately -- which includes knowing the limits of how precisely terms like fulfill and resolve can really be distinguished. Jake Archibald admits that he sometimes gets the terms mixed up. That's a very helpful admission to noobs like me who are trying to make sense of terminology! Thank you, Jake, for being vulnerable. :-) My purpose in asking this question is to find out, which definitions or usages of those terms are reliable? Or should I conclude that resolve is sometimes used specifically to mean fulfill, and sometimes fulfill/reject/lock in, even in the most authoritative documents?

推荐答案

我正在努力解决 resolve 的基本概念和已解决，与履行和已履行。

I'm struggling with the basic notions of resolve and resolved, vs. fulfill and fulfilled.

查看 javascript承诺的正确术语是什么。是的，它们有时会混淆，但让我们试着忽略它。

Have a look at What is the correct terminology for javascript promises. Yes, they're sometimes mixed up, but let's try to ignore that.

然而规范指的是<$的第一个参数c $ c> then（）使用履行和解决的方法（或其相应的抽象概念）。我们是否以不一致的方式结束了应该成为运动指导灯的文件？

Yet the spec refers to the first argument to the then() method (or its corresponding abstract concepts) using both fulfill and resolve. Did we end up with the documents that are supposed to be the guiding lights of the movement using terms in inconsistent ways?

不，那里这里没有不一致，规范中的条款是准确的。

No, there is no inconsistency here, the terms in the spec are accurate.

解决与拒绝不同，并且 onFulfilled 回调与解析并不完全对应。

resolve is not the opposite of reject, and the onFulfilled callback does not exactly correspond to resolving.

或者是否有我遗漏的内容， resolve 实际上是一个比履行更合适的术语 resolve（）方法吗？

Or is there something I'm missing, and resolve is actually a more appropriate term than fulfill for what the resolve() method does?

是的。问题是你可以解决一个承诺（或者一般来说，一个版本，即任何带有然后方法的对象），而不是为了满足该对象，已解决的承诺将尝试使用theable的结果来实现。或者当那个人有（会有）一个错误时，它会拒绝那个原因。

Yes. The problem is that you can resolve with a promise (or in general, a thenable, i.e. any object with a then method), and instead of fulfilling with that object the resolved promise will try to fulfill with the thenable's result. Or when the thenable has (will have) an error, it will reject with that as the reason.

没有提及[在MDN ] Promise.resolve（）方法有可能拒绝。

实际上有：返回的承诺将跟随那个可行的，采用其最终状态。如果该最终状态是错误状态，则返回的承诺也将拒绝。

Actually there is: "the returned promise will "follow" that thenable, adopting its eventual state". If that eventual state is the error state, then the returned promise will reject as well.

有一个承诺.reject（）方法，但没有 Promise.fulfill（）方法。所以在这里，拒绝的对应部分是解决，而不是履行。

There is a Promise.reject() method, but no Promise.fulfill() method. So here, the counterpart to reject is resolve, instead of fulfill.

是的，ES6承诺缺少 Promise.fulfill 方法。这一点有点不一致和令人困惑，但是有充分理由这样做：它阻止你有一个履行了另一个承诺的承诺。你只能解决 ES6承诺，当你传递一个承诺时，它的结果将不是承诺对象。

Yes, ES6 promises are lacking a Promise.fulfill method. This is a bit inconsistent and confusing at first, but was done for a good reason: It prevents you from having a promise that is fulfilled with another promise. You can only resolve ES6 promises, and when you pass in a promise it will take its result not the promise object by itself.

这是非常有用，但也很不方便。有些库可以做得更好并允许这种情况，它们就是所谓的代数承诺（你可以推理得更好）。 信条就是一个很好的例子，它的 Promise.of 方法是 Promise.reject 的真正对应方。

This is pretty useful, but can be pretty inconvenient as well. There are libraries that do it better and allow this case, they're so-called "algebraic promises" (which you can reason about a lot better). Creed is a good example of that, and its Promise.of method is a real counterpart to Promise.reject.

这篇关于是否“解决”始终意味着与“履行”不同的东西？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！