A Challenge Problem for Promise Designers (was: Re: Futures)

Dean Tribble tribble at e-dean.com
Thu Apr 25 18:03:16 PDT 2013

Hmm. I agree that the example code isn't relevant to JavaScript. For
background, the last time issues this came up for me was in the context of
a language keyword (which had other interesting but unrelated trade offs),
where it really did impose that interaction (call sites had to declare that
the type was a promise, and handle that, even though they were then
returning promises).  I'm glad we agree that needing to "then" in the
tail-call case would be silly for a promise library. So what's an example
that motivates you to want to build a tower of promise types?  The main one
I know of is the implementation (not use of) higher-order collection
constructs that use promises internally (e.g., the implementation of map
and reduce for an async,  batching, flow-controlled stream of Promise<T>).
That kind of rare example can have more advanced hooks (like Q).

On Thu, Apr 25, 2013 at 5:08 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> ... If cacheService.getLength() returns a future, then you don't need to do
> anything special in the size() function - just return the future that
> it returns.  It sounds like you're nesting values in futures for the
> hell of it, which of course is problematic.  Hiding the application's
> mistakes by auto-flattening isn't a good idea....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130425/2b842c1e/attachment.html>

More information about the es-discuss mailing list