W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: [futures] Add convenience functions for immediate/canceled promises

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 18 Apr 2013 10:03:46 -0700
Message-ID: <CAAWBYDDKEythi02qVB5CcvUUq4iCOkh-12=__8bb28oPNSOqfw@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Brandon Wallace <brandon.wallace@yahoo.com>, "www-dom@w3.org" <www-dom@w3.org>
On Fri, Apr 12, 2013 at 11:10 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, Apr 11, 2013 at 4:57 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
>> The conventional name for these two methods would be Future.resolve and Future.reject. The implementation would be
>> Future.resolve = (x) => new Future(({ resolve }) => resolve(x));
>> Future.reject = (reason) => new Future(({ reject }) => reject(reason));
>> This has the added benefit of using "resolve" semantics, i.e. assimilating thenables (including existing promises on the web, like jQuery promises).
> Now that I've actually learned the difference between accept() and
> resolve(), I'd prefer that all three of the resolution methods exist
> as statics on the Future interface.  You don't always want resolve
> semantics.

And, having thought about it more and been working on a
closely-related EventStreams proposal, I actually now propose the
following names:

Future.of(any value) => Returns an accepted future with that value.
Future.from(any value) => If the value is future-like, resolves on it.
 Otherwise, identical to Future.of
Future.reject(any reason) => Returns a rejected future with that reason.

Each are identical to:

function (value) {
  return new Future(function(r) { r.[accept/resolve/reject](value); }

The naming suggestions are meant to (a) parallel the collection APIs,
particularly Array, which uses Array.of() as a "simple constructor"
(really, it's the monadic lifting function), and uses Array.from() as
the "conversion constructor".  I think these are readable and easy to
understand, and while there are good arguments for simple copying the
resolver's method naming, I think it's even better to follow the
developing naming standard I lay out above.

Received on Thursday, 18 April 2013 17:04:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC