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

Tab Atkins Jr. jackalmage at gmail.com
Fri Apr 19 18:41:36 PDT 2013


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