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

Re: Futures

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 23 Apr 2013 11:02:58 -0700
Message-ID: <CAAWBYDDw_R98G7=08SwbjJksTMVn+wYOSAi0fWOVCQ9FDPUdZg@mail.gmail.com>
To: David Bruant <bruant.d@gmail.com>
Cc: Dean Landolt <dean@deanlandolt.com>, Brendan Eich <brendan@mozilla.com>, "Mark S. Miller" <erights@google.com>, Douglas Crockford <douglas@crockford.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Norbert Lindenberg <w3@norbertlindenberg.com>, Markus Lanthaler <markus.lanthaler@gmx.net>, EcmaScript <es-discuss@mozilla.org>
On Tue, Apr 23, 2013 at 6:12 AM, David Bruant <bruant.d@gmail.com> wrote:
> Anyway, my point was that there exist libraries in which "then" is a
> function and the object with this function isn't a promise. These libraries
> will end up in a terrible confusion when used with Futures.
> You think you're resolving a future with an object and... oops! the built-in
> Future algorithm confused your object for a promise. Suddenly, not only are
> you not resolving your promise with the value, but your .then method is
> called unexpectedly.

Agreed.  I'll note, though, that if the semantics of .resolve() are
non-recursive (it strips off one layer of promise/future, but no
further), then this becomes somewhat less of an issue, as it can be
worked around - if you want to return something that's not a promise,
just wrap it in a fulfilled promise (via some sugar function - I've
proposed such in www-dom).  That wrapper will be unwrapped straight
away, and the future accepted with the value within.

The big problem only arrives if you both treat all thenables as
promises/futures, *and* have recursive resolve semantics, because then
you can't *ever* return a non-promise with a .then() method.

I'd prefer that resolve only strip away a branded future, not an
arbitrary thenable, and for there to be a way to brand a thenable as a
future.  That way, using other-library promises just requires one trip
through the branding function and they can interoperate.  Existing
libraries tend to expose the same mechanism already, so that the
other-library promises expose all the proper methods of the "main"
library.

But I want non-recursive resolve *more*, and if I was forced to choose
one, would take monadic resolve over branded futures.

~TJ
Received on Tuesday, 23 April 2013 18:03:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC