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:[email protected]] 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 <[email protected]> wrote: >> -----Original Message----- >> From: Tab Atkins Jr. [mailto:[email protected]] >> 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 <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
