Futures (was: Request for JSON-LD API review)

Ron Buckton rbuckton at chronicles.org
Tue Apr 23 17:16:39 PDT 2013


I put up a rough DOM Future polyfill (with a few additions for experimentation) at: https://github.com/rbuckton/promisejs

It has:
* Future
* Future#then (tentatively adds the options argument in my proposal for forcing synchronous execution of continuation)
* Future#done (tentatively adds the options argument in my proposal for forcing synchronous execution of continuation)
* Future#catch (tentatively adds the options argument in my proposal for forcing synchronous execution of continuation)
* Future.of (extension. coerces thenables)
* Future.isFuture (extension. Checks branding using a pseudo-symbol, cross-realm only for ES5+)
* Future.resolve
* Future.reject
* Future.any
* Future.some (with properly ordered reject array value)
* Future.every (with properly ordered resolve array value)
* Future.yield (extension. Helpful for "await"-style asynchrony or yielding to another waiting task in the dispatcher)
* Future.sleep (extension. Helpful for "await"-style asynchrony and timeouts)
* Future.sleepUntil (extension. Something like a SpinWait primitive for "await"-style asynchrony)
* Future.run (extension. Runs a callback in a later turn or after a delay)
* FutureResolver (not creatable)
* FutureResolver#accept
* FutureResolver#resolve (only chains branded Future instances)
* FutureResolver#reject
* Deferred (extension. Extracts and encapsulates the resolver for use cases like "cancellation-by-future")

I'm considering adding a Future#finally as well, as I've found some use cases in a Future-based AMD module loader I'm tinkering with.

Ron


-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage at gmail.com] 
Sent: Friday, April 19, 2013 6:42 PM
To: Ron Buckton
Cc: Kevin Gadd; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API review)

On Fri, Apr 19, 2013 at 6:37 PM, Ron Buckton <rbuckton at chronicles.org> wrote:
>> -----Original Message-----
>> From: Tab Atkins Jr. [mailto:jackalmage at gmail.com]
>> Sent: Friday, April 19, 2013 5:18 PM
>> To: Kevin Gadd
>> Cc: Ron Buckton; es-discuss
>> Subject: Re: Futures (was: Request for JSON-LD API review)
>>
>> On Fri, Apr 19, 2013 at 4:02 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
>>
>> One simple possibility would be to just expose accept/resolve/reject 
>> on the returned Future itself.  Calling any of these cancels the 
>> Future (if the Future has a notion of cancellation), and forces it to 
>> adopt the passed state as appropriate.  The constructor would take 
>> two callbacks, one for normal operation (called immediately) and one 
>> to handle cancellation (called when needed).  This has the nice 
>> benefit that a consumer can provide a default value for other 
>> consumers to use, and it doesn't require any new codeflow channels.
>
> I'd be more interested in having a creatable FutureResolver with a .future accessor property for those cases. Given the current API, its possible (but not pretty) to do something like:

That doesn't help our main use-cases, which is allowing you to get a cancelable future out of *platform* APIs, where the platform constructs the future for you.

>> It would be so nice if JS had multiple return values, so we could let 
>> cancellable future-returning APIs just return a naked resolver as 
>> their second value, and only clueful call sites would need to care 
>> about it.  ^_^  Instead, we'll probably need to have API variants 
>> that instead return something like a Deferred, or that return a pair of a future and a resolver.
>
> That sounds like what I just mentioned in https://gist.github.com/rbuckton/5424214.

It's inverted, actually, but it works out similarly.  That might be the way to go - it lets you keep a single calling function, but still optionally send in cancellation notices.

~TJ



More information about the es-discuss mailing list