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. <[email protected]>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....
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
