On Tue, Apr 23, 2013 at 6:41 PM, Brendan Eich <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
