A Challenge Problem for Promise Designers (was: Re: Futures)

Domenic Denicola domenic at domenicdenicola.com
Fri Apr 26 07:27:22 PDT 2013


From: David Sheets [kosmo.zb at gmail.com]

> From my reading, DOM Futures doesn't state anything about resolution semantics, to its detriment, but abstracts those semantics behind `FutureResolver`.

This is not correct. See "Let resolve be a future callback for the context object and its resolve algorithm." inside the resolve algorithm itself. DOM Futures are recursive, just like Promises/A+.

> Have I presented this correctly?

Yes.

> Why is it a problem to specify a single level of assimilation instead of sometimes-flattening "thenables" but never flattening promises?

The idea is that conformant libraries may want to prohibit promises-for-thenables (since, as discussed many times already, they are nonsensical, unless you care more about monads than you do about promises---which all promise libraries I know of do not). To do so, two things must occur:

1. The library must never allow creation of promises-for-thenables. That is, it must not provide a `fulfilledPromise(value)` method, only a `resolvedPromise(value)` method. DOM Future violates this by providing `accept(value)`, but presumably TC39-sanctioned promises will not provide such a method.

2. The library must prevent thenables-for-thenables from turning into promises-for-thenables via assimilation. Instead, it must do recursive unwrapping.

In this way, Promises/A+ allows promises-for-promises within a library, if that library allows creation of such things in the first place (like DOM Future does). But it does not allow promises-for-thenables, i.e. it does not allow foreign promises-for-promises to infect a library with multiple layers of wrapping. Multi-layered wrapping *must* stay within a single library.


(In the above I am using "thenable" in the sense it is used today, i.e. "object with a then method," not Claus's version.)



More information about the es-discuss mailing list