Riguardo a Promises / A + Specification, qual è la differenza tra i termini “thenable” e “promise”?

Sto verificando la specifica “Promises / A +”, ma non ho potuto capire le seguenti cose:

Nella sezione 1. Terminologia,

1.1. "promise è un object o una funzione con un metodo then il cui comportamento è conforms a questa specifica.

1.2. “thenable” è un object o una funzione che definisce un metodo allora.

Quindi qual è la differenza tra i termini "thenable" e "promise" ?

Anche nella sezione 2.3. La procedura di risoluzione della promise,

La procedura di risoluzione delle promesse è un’operazione astratta che prende come input una promise e un valore, che denotiamo come [[Resolve]](promise, x) .

Quindi la mia domanda è:

Perché è indicato con 2 parentesi di apertura e chiusura? C’è qualche convenzione?

Grazie mille.

Quindi qual è la differenza tra i termini “thenable” e “promise”?

Penso che la sezione che hai già citato risponde molto bene:

  • Un thenable è un object con un metodo then . Qualsiasi object
  • Una promise è un object con un metodo then (cioè un thenable) conforms alle specifiche .

Fin qui molto semplice. Penso che la tua vera domanda sia: ” Perché sono distinti?

Il problema è che guardando un object non puoi decidere se è una promise.
Potresti essere in grado di dire che è una promise perché puoi vedere che il suo metodo then è implementato da te o da qualcuno di cui ti fidi – la biblioteca di tua scelta di solito. Sareste in grado di “vederlo” perché l’object eredita dal prototipo di una promise, o potete anche confrontare il metodo essendo (referenzialmente) identico alla funzione che avete definito. O qualsiasi altro metodo di ispezione che è sufficiente per te.
Potresti essere in grado di dire che non è una promise perché non ha alcun metodo.
Ma cosa fai con un object che implementa then , ma non è noto per essere una promise? È un valore accettabile e sarà gestito come tale.

La specifica Promises / A + mira all’interoperabilità tra le implementazioni di promise e utilizza l’esistenza di un metodo .then() per la digitazione anatra . Specifica un algoritmo esatto su come trattare tali argomenti (che potrebbero essere promesse o almeno avere un comportamento simile) in modo da poter creare da loro una promise reale, attendibile (“conosciuta”).

Perché è indicato con 2 parentesi di apertura e chiusura? C’è qualche convenzione?

Sì, le specifiche ECMAScript utilizzano questa syntax per i metodi e le proprietà interni :

I nomi delle proprietà interne sono racchiusi tra parentesi quadre [[]].

Queste proprietà in realtà non hanno bisogno di esistere, sono puramente utilizzate per descrivere ciò che dovrebbe accadere: un’implementazione deve comportarsi come se le usasse. Sono comunque operazioni totalmente astratte.

Questo è un tentativo intelligente per rendere più facile l’interoperabilità delle promesse tra diverse librerie.

La specifica usa il termine ” thenable in pochi punti. Questo è il più importante (miniera di empatia):

La procedura di risoluzione delle promesse è un’operazione astratta che prende come input una promise e un valore, che denotiamo come [[Resolve]](promise, x) . Se x è una variabile , tenta di far sì che la promise adotti lo stato di x, assumendo che x si comporti almeno in qualche modo come una promise. Altrimenti, soddisfa la promise con il valore x.

Ciò renderà gli implementatori fare un controllo come:

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

Se invece la specifica dicesse “se x è una promise, allora …” , come potrebbe l’implementatore sapere se x è una promise o no? Non esiste un modo pratico per assicurarsi che x sia conforms alle specifiche Promise semplicemente controllandolo.

Un implementatore (diciamo, la libreria FooPromises potrebbe fare qualcosa di simile

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

e rigetterebbe efficacemente qualsiasi promise proveniente da diverse implementazioni.

Invece, usando una definizione super-semplice di thenable in questa condizione che gli implementatori possono facilmente verificare, è banale fare questo controllo e rendere ansible alle implementazioni di giocare bene l’uno con l’altro.


Per la seconda domanda, non sono sicuro, ma la mia idea sarebbe che una notazione [[Resolve]](promise, x) enfatizzi che si tratta di un’operazione astratta. Se hanno lasciato cadere le parentesi e ha appena detto Resolve(promise, x) , ciò implicherebbe in qualche modo che gli implementatori debbano fare una funzione reale chiamata Resolve ed esporla.

Questo non è necessario – Resolve non fa parte dell’interfaccia delle promesse; è solo una parte del loro comportamento che è stato abbastanza importante da dare un nome e una sezione separata nei documenti.