Betreffend Promises/A + Specification, was ist der Unterschied zwischen den Begriffen "thenable" und "promise"?

Question

ich Auschecken der "Promises/A +" Specification, konnte aber die folgenden Dinge nicht verstehen:

Zu § 1. Terminologie,

1.1. ist ein Objekt oder eine Funktion mit einer then-Methode, deren Verhalten dieser Spezifikation entspricht.

1.2. “thenable” ist ein Objekt oder eine Funktion, die eine then-Methode definiert.

Was ist der Unterschied zwischen den Begriffen "thenable" und "promise"?

Auch in Abschnitt 2.3. Das Promise Resolution Procedure,

Das Promise Resolution-Verfahren ist eine abstrakte Operation, die als Eingabe ein Versprechen und einen Wert nimmt, den wir als [[Resolve]](promise, x) bezeichnen.

Also meine Frage ist:

Warum ist es innerhalb von 2 Öffnen und Schließen Klammern bezeichnet? Gibt es eine Konvention?

Vielen Dank.

Answer 1

Dies ist ein kluger Versuch, Interoperabilität zwischen verschiedenen Bibliotheken zu erleichtern.

Die Spezifikation verwendet den Begriff thenable nur an wenigen Stellen. Dieser ist der wichtigste (empasis von mir):

Das Versprechen Beilegungsverfahren ist eine abstrakte Operation als Eingabe nimmt ein Versprechen und einen Wert, die wir als [[Resolve]](promise, x) bezeichnen. Wenn x ein anschließbares ist, versucht es Versprechen zu machen, den Zustand von x anzunehmen, unter der Annahme, dass sich x zumindest etwas wie ein Versprechen verhält. Ansonsten erfüllt es Versprechen mit dem Wert x.

Dies wird Implementierer auszukommen eine Überprüfung wie:

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

Wenn stattdessen die spec sagte „wenn x ein Versprechen ist, dann ...“, wie die Implementierer wissen würde, ob x ist ein Versprechen oder nicht? Es gibt keinen praktischen Weg, um sicherzustellen, dass x die Promise-Spezifikation nur bei der Überprüfung erfüllt.

Ein Implementierer (sagen wir, Bibliothek FooPromises könnte etwas tun, wie

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

und es würde keine Versprechungen wirksam ablehnen aus verschiedenen Implementierungen kommen.

Stattdessen durch eine super-einfache Definition von thenable Verwendung in Diese Bedingung, die die Implementierer leicht überprüfen können, ist trivial und macht es möglich, dass Implementierungen gut miteinander spielen.

---

Für Sie zweite Frage, ich bin nicht sicher, aber meine Idee wäre, dass eine Notation [[Resolve]](promise, x) betont, dass es sich um eine abstrakte Operation ist. Wenn sie die Klammern fallen ließen und nur Resolve(promise, x) sagten, würde das bedeuten, dass die Implementoren eine echte Funktion mit dem Namen Resolve erstellen und sie offen legen sollten.

Dies ist nicht erforderlich - Resolve ist nicht Teil der Versprechen 'Schnittstelle; Es ist nur ein Teil ihres Verhaltens, der wichtig genug war, dass es in den Dokumenten einen Namen und einen separaten Abschnitt erhielt.

Answer 2

Was ist der Unterschied zwischen den Begriffen "thenable" und "promise"?

ich glaube, der Abschnitt, den Sie schon nicht haben zitiert diese Antwort sehr gut:

• A thenable ist ein Objekt mit einem then Verfahren. Jedes Objekt.
• Ein Versprechen ist ein Objekt mit einer then-Methode (d. H. Eine thinable) , die der Spezifikation entspricht.

So weit so einfach. Ich denke, Ihre eigentliche Frage ist: "Warum unterscheiden sie sich?"

Das Problem ist, dass durch das Betrachten eines Objekts können Sie nicht entscheiden, ob es ein Versprechen ist.
Sie könnte in der Lage zu sagen, dass es ein Versprechen ist, weil Sie sehen können, dass seine then Methode von Ihnen selbst oder jemand, dem Sie vertrauen, die Versprechen Bibliothek Ihrer Wahl in der Regel implementiert wird. Sie könnten das "sehen", weil das Objekt von Ihrem Versprechensprototyp erbt, oder Sie können sogar die Methode vergleichen, die (referentiell) mit der von Ihnen definierten Funktion identisch ist. Oder eine andere Prüfmethode, die für Sie ausreichend ist.
Sie könnte in der Lage zu sagen, dass es kein Versprechen ist, weil es keine then Methode hat.
Aber was machst du mit einem Objekt, das then implementiert, aber ist nicht bekannt, ein Versprechen zu sein? Es ist ein thenable, und wird als solches behandelt.

Die Promises/A + -Spezifikation zielt auf die Interoperabilität zwischen Versprechungsimplementierungen ab und verwendet das Vorhandensein einer -Methode für duck typing. Es gibt einen genauen Algorithmus für die Behandlung solcher thenables (dass könnte Versprechen oder zumindest ähnliches Verhalten haben), so dass Sie eine tatsächliche, vertrauenswürdige ("bekannte") Versprechen von ihnen erstellen können.

Warum wird es innerhalb von 2 öffnenden und schließenden Klammern angegeben? Gibt es eine Konvention?

Ja, verwenden die ECMAScript-Spezifikationen diese Syntax für internal methods and properties:

Die Namen der internen Eigenschaften werden in doppelten eckigen Klammern [[]].

Diese Eigenschaften tatsächlich nicht existieren müssen, sind sie rein zu beschreiben, was passieren soll - eine Implementierung handeln müssen, als ob es ihnen verwendet werden. Sie sind jedoch total abstrakte Operationen.