On Thu, Aug 8, 2013 at 10:24 PM, Domenic Denicola < domenic@domenicdenicola.com> wrote: > I would strongly advise against conflating progress (ongoing > notifications about a streaming async operation) and promises (one-and-done > async operations). The promise implementer community in general, and the > Promises/A+ organization in particular, has found this to be an extremely > problematic line of reasoning, and one that does not mesh well with the > existing semantics or syntax of promises. It has led to increased confusion > from our users and a muddling of the underlying conceptual model, > especially e.g. as it pertains to error handling. The fact that any > progress additions to the promise API have no place in a shallow > coroutine-based syntax enhancement of promises (e.g. C#’s await, or ES6’s > yield) further strengthens our view.**** > > ** > It's discussed with a name "ProgressPromise" but I think what we need and drafting and Promise are not cleanly under as-is relationship (for example, data represented by ProgressPromise will be CONSUMED by progress callbacks already set and already consumed partial sequence of data won't be delivered to callbacks set later). For Streams API (and maybe also for fileapi), it would be useful if we build and use something lazily delivers possibly infinite sequence of data + end signal + failure. It would be similar to Promise from some point of view, and maybe we'd reuse lots of code now used for Promise to implement it. So I'm discussing it together with Promise.
Received on Thursday, 8 August 2013 14:13:40 UTC