Re: [promise] writing detailed spec of ProgressPromise & implementing it

On Thu, Aug 8, 2013 at 2: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.

What goes wrong with error handling?


> As such I would ask you to consider alternate APIs that do not involve
> awkwardly stuffing streaming async semantics into one-and-done promises. For
> example, whichever object vends promises could be an EventTarget emitting
> progress events, or could instead of vending promises directly vend {
> promise, progressEmitter } pairs.

The latter is pretty much what ProgressPromise would be. The former
seems kind of annoying as you'd have several styles intermixing.


I can understand the hypothetical that we might later decide this is
the wrong thing and we'd have some unnecessary complexity. I don't
really understand how it would limit extensibility.


-- 
http://annevankesteren.nl/

Received on Thursday, 8 August 2013 13:38:43 UTC