W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

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

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Fri, 26 Apr 2013 14:27:22 +0000
To: David Sheets <kosmo.zb@gmail.com>, Juan Ignacio Dopazo <dopazo.juan@gmail.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F7EF5BFA2@BY2PRD0510MB354.namprd05.prod.outlook.com>
From: David Sheets [kosmo.zb@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?


> 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.)

Received on Friday, 26 April 2013 14:27:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC