javascript - promises - promise typescript

Con respecto a la especificación Promesas/A+, ¿cuál es la diferencia entre los términos "admisible" y "promesa"?

Question

Estoy revisando la especificación "Promesas / A +", pero no pude entender lo siguiente:

En la Sección 1. Terminología,

1.1. "promise” es un objeto o función con un método de entonces cuyo comportamiento se ajusta a esta especificación.

1.2. “thenable” es un objeto o función que define un método then.

Entonces, ¿cuál es la diferencia entre los términos "thenable" y "promise" ?

También en la Sección 2.3. El procedimiento de resolución de promesas,

El procedimiento de resolución de promesas es una operación abstracta que toma como entrada una promesa y un valor, que denotamos como [[Resolve]](promise, x) .

Entonces mi pregunta es:

¿Por qué se denota dentro de 2 paréntesis de apertura y cierre? ¿Hay alguna convención?

Muchas gracias.

Answer 1

Entonces, ¿cuál es la diferencia entre los términos "admisible" y "promesa"?

Creo que la sección que ya has citado responde muy bien a esto:

• Un thenable es un objeto con un método then . Cualquier objeto
• Una promesa es un objeto con un método then (es decir, un thenable) que se ajusta a la especificación .

Hasta ahora muy simple. Creo que su pregunta real es: " ¿Por qué se distinguen? "

El problema es que al mirar un objeto no puedes decidir si es una promesa.
Es posible que pueda decir que es una promesa porque puede ver que su método lo implementa usted mismo o alguien en quien confía: la biblioteca de promesas de su elección por lo general. Podría "ver" eso porque el objeto hereda de su prototipo de promesa, o incluso puede comparar el método que es (referencialmente) idéntico a la función que ha definido. O cualquier otro método de inspección que sea suficiente para usted.
Es posible que pueda decir que no es una promesa porque no tiene un método.
Pero, ¿qué haces con un objeto que se implementa then , pero que no se sabe que es una promesa? Es un thenable , y será manejado como tal.

La especificación Promises / A + tiene como objetivo la interoperabilidad entre las implementaciones de promesas, y utiliza la existencia de un método .then() para escribir a los patos . Especifica un algoritmo exacto sobre cómo tratar dichos objetos no admitidos (que podrían ser promesas o al menos tener un comportamiento similar) para que pueda crear una promesa real, confiable ("conocida") a partir de ellos.

¿Por qué se denota dentro de 2 paréntesis de apertura y cierre? ¿Hay alguna convención?

Sí, las especificaciones ECMAScript usan esta sintaxis para métodos y propiedades internos :

Los nombres de las propiedades internas están encerrados entre corchetes dobles [[]].

Esas propiedades en realidad no necesitan existir, solo se usan para describir lo que debería suceder; una implementación debe actuar como si las usara. Sin embargo, son operaciones totalmente abstractas.

Answer 2

Este es un intento inteligente para facilitar que las promesas sean interoperables entre diferentes bibliotecas.

La especificación utiliza el término thenable en solo unos pocos lugares. Este es el más importante (empasis mío):

El procedimiento de resolución de promesas es una operación abstracta que toma como entrada una promesa y un valor, que denotamos como [[Resolve]](promise, x) . Si x es un thenable , intenta hacer que la promesa adopte el estado de x, bajo el supuesto de que x se comporta al menos algo como una promesa. De lo contrario, cumple la promesa con el valor x.

Esto hará que los implementadores hagan una verificación como:

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

Si la especificación decía "si x es una promesa, entonces ..." , ¿cómo sabría el implementador si x es una promesa o no? No hay una forma práctica de asegurarse de que x cumple con la especificación de Promise con solo inspeccionarla.

Un implementador (por ejemplo, la biblioteca FooPromises podría hacer algo como

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

y rechazaría efectivamente cualquier promesa proveniente de diferentes implementaciones.

En cambio, al usar una definición súper simple de thenable en esta condición que los implementadores pueden verificar fácilmente, es trivial hacer esta verificación y hacer posible que las implementaciones funcionen bien entre sí.

Para su segunda pregunta, no estoy seguro, pero mi idea sería que una notación [[Resolve]](promise, x) enfatiza que es una operación abstracta. Si se caen los corchetes y solo dicen Resolve(promise, x) , de alguna manera implicaría que los implementadores deben hacer una función real llamada Resolve y exponerla.

Esto no es necesario: Resolve no es parte de la interfaz de las promesas; es solo una parte de su comportamiento lo suficientemente importante como para que se le haya dado un nombre y una sección separada en los documentos.