Futures

Tab Atkins Jr. jackalmage at gmail.com
Tue Apr 23 21:49:53 PDT 2013


On Tue, Apr 23, 2013 at 6:41 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Tab Atkins Jr. wrote:
>> Yeah, that's fine when you're explicitly invoking something that needs
>> to return two objects.
>
> You didn't grok what I wrote. The object is erased, and the value(s) are
> returned to the caller depending on the pattern it uses.
>
>
>> It's less fine when you have something like a hypothetical getJSON()
>> (future-returning XHR sugar), which can reasonably just return a
>> future, but which we also want to make cancellable.  Burdening *every*
>> call site
>
>
> No, you can use a smaller pattern, e.g.
>
> let { future } = getJSON();
>
> instead of
>
> let { future, cancel } = getJSON();

No, I absolutely grok what you wrote. I still think that burdening the
call-site with the need to pull a future out of the object like that
(even though, yes, the object itself will be optimized out by future
VMs) is too much.  It also means that we can't upgrade a function from
returning a future to returning a cancellable future - we'll have to
mint a new name.

I think my preferred method is to have cancellable futures be a
subtype of futures, which expose a .resolver property on themselves,
and which return a normal future from their .then() function.  (It
doesn't make sense for the chained future to continue to be
cancellable, because what's being cancelled? It's not natural, I
think, to let a downstream future hold a resolver for an upstream one.
Thus, there's no need for the downstream to be cancellable at all.)

This keeps the two objects separate, and lets you "clean" a
cancellable future for passing to untrusted code by calling .then()
with no arguments.

~TJ


More information about the es-discuss mailing list