A Challenge Problem for Promise Designers (was: Re: Futures)
tribble at e-dean.com
Thu Apr 25 18:03:16 PDT 2013
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...
More information about the es-discuss