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

>
> I don't believe that's what I'm saying. I am saying that ProgressPromise
> is a bad idea, no matter where it is defined, and for reasons that have
> nothing to do with breaking existing Promise functionality.


Hmm... You said that

> As such, I would suggest representing it as such a side-channel. In
> particular, for your directory-picker UI, I'd suggest an object such as `{
> openSystemDirectoryPicker, addEventListener }`, or if you think that's not
> ergonomic, then have `openSystemDirectoryPicker` return an object that
> implements both `Promise` and `EventTarget` interfaces. A special
> progress-promise, that departs from standard `EventTarget` mechanisms and
> presumably entangles itself into the resolver etc., causes the problems
> outlined above.

before. Is "an object that implements both `Promise` and `EventTarget`
interfaces" a simple Promise object?
Then, why is "an object that implements Promise and has `progress' method"
bad?
For StreamsAPI, we don't have to define ProgressPromiseResolver even if we
define ProgressPromise (or whatever its name is), I think.

On Fri, Aug 9, 2013 at 10:13 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: Yutaka Hirano [mailto:yhirano@google.com]
>
> > Domenic, your opinion is
> > 1. If the progress mechanism affects the existing Promise functionality,
> it will break the Promise functionality.
> > 2. Otherwise, ProgressPromise should be defined out of this spec.
> >, is that correct?
>
> I don't believe that's what I'm saying. I am saying that ProgressPromise
> is a bad idea, no matter where it is defined, and for reasons that have
> nothing to do with breaking existing Promise functionality.
>
> > Is it OK with you to define a kind of ProgressPromise interface in the
> second way in Streams API?
>
> I think defining a streams API is a fine idea. I think that streams API
> should definitely *not* use or define any kind of ProgressPromise, i.e. it
> should *not* have a method like `AbortableProgressPromise<ArrayBuffer>
> read(n)`. It should instead simply have `Promise<ArrayBuffer> read(n)`. I
> have not yet gotten around to replying to Jonas's question as to why this
> is important, and will try to do so later today.
>