Regarding Promises/A+ Specification, what is the d

问题:

I am checking out the \"Promises/A+\" Specification, but could not understand the following things:

On Section 1. Terminology,

1.1. \"promise” is an object or function with a then method whose behavior conforms to this specification.

1.2. “thenable” is an object or function that defines a then method.

So What is the difference between the terms \"thenable\" and \"promise\"?

Also in Section 2.3. The Promise Resolution Procedure,

The promise resolution procedure is an abstract operation taking as input a promise and a value, which we denote as [[Resolve]](promise, x).

So my question is:

Why is it denoted within 2 opening and closing brackets? Is there any convention?

Thank you very much.

回答1:

So What is the difference between the terms \"thenable\" and \"promise\"?

I think the section you\'ve already cited does answer this very well:

• A thenable is an object with a then method. Any object.
• A promise is an object with a then method (i.e. a thenable) that conforms to the specification.

So far so simple. I think your actual question is: \"Why are they distinguished?\"

The problem is that by looking at an object you cannot decide whether it is a promise.
You might be able to tell that it is a promise because you can see that its then method is implemented by yourself or someone you trust - the promise library of your choice usually. You would be able to \"see\" that because the object does inherit from your promise prototype, or you can even compare the method being (referentially) identical to the function you\'ve defined. Or any other inspection method that is sufficient for you.
You might be able to tell that it is not a promise because it has no then method.
But what do you do with an object that implements then, but is not known to be a promise? It\'s a thenable, and will be handled as such.

The Promises/A+ specification aims for interoperability between promise implementations, and uses the existence of a .then() method for duck typing. It does specify an exact algorithm on how to treat such thenables (that might be promises or at least have similar behaviour) so that you can create an actual, trusted (\"known\") promise from them.

Why is it denoted within 2 opening and closing brackets? Is there any convention?

Yes, the ECMAScript specifications use this syntax for internal methods and properties:

The names of internal properties are enclosed in double square brackets [[ ]].

Those properties do not actually need to exist, they\'re purely used to describe what should happen - an implementation must act as if it used them. They are totally abstract operations though.

回答2:

This is a smart attempt to make it easier for promises to be interoperable between different libraries.

The spec uses the term thenable in just a few places. This one is the most important (empasis mine):

The promise resolution procedure is an abstract operation taking as input a promise and a value, which we denote as [[Resolve]](promise, x). If x is a thenable, it attempts to make promise adopt the state of x, under the assumption that x behaves at least somewhat like a promise. Otherwise, it fulfills promise with the value x.

This will make implementors do a check like:

if (typeof(x.then) === \'function\') {
    // adopt the state of x
} else {
    // fulfill promise with value x
}

If the spec instead said \"if x is a promise, then...\", how would the implementor know whether x is a promise or not? There\'s no practical way to make sure if x complies with the Promise spec just by inspecting it.

An implementor (say, library FooPromises might do something like

if (x instanceof FooPromises.Promise) {
    // adopt the state of x
} else {
    // fulfill promise with value x
}

and it would effectively reject any promises coming from different implementations.

Instead, by using a super-simple definition of thenable in this condition that implementors can easily verify, it\'s trivial to make this check and you make it possible for implementations to play nice with each other.

---

For you second question, I\'m not sure but my idea would be that a notation [[Resolve]](promise, x) emphasises that it\'s an abstract operation. If they dropped the brackets and just said Resolve(promise, x), it would somehow imply that implementors should make a real function named Resolve and expose it.

This is not needed - Resolve is not part of the promises\' interface; it\'s just a part of their behaviour that was important enough that it was given a name and a separate section in the docs.