Split out Future from DOMFuture?

[slightlyoff]

@annevk recommends that it might be good to have an EventTarget-free version of Future specified here for use by Mozilla. I agree that we need it.

[DavidBruant]

What does "for use by Mozilla" means? Is there a related discussion/bug to follow?

[annevk]

We had some offline discussions with @sicking et al. I think the main advantage is that we can make it a native JavaScript / IDL type.

@sicking also seemed to feel that we should not use events at all, but rather add callbacks whenever needed.

[slightlyoff]

Discussed the event thing yesterday and I think we don't need to drop 'em, but I'm OK with doing the subclassing exercise to pave the way for TC39

[jakearchibald]

What's the disadvantage of Future being an EventTarget? It's useful for progress-style events.

[annevk]

@jakearchibald, @sicking has been suggesting to use a Future-subclass with an additional callback for progress-style events. I think @slightlyoff prototyped one and put it in the repository.

[jakearchibald]

Shouldn't progress-style events be events?

The benefit of Futures is they either resolve or reject, both can't happen and neither happen more than once. Adding a then(func1, func2) callback after resolve/reject will still call func1 or func2.

Something that can fire more than once and only calls listeners that are registered when the events happens... that's just events right?

[domenic]

Here's the problem with pure-event progress handlers:

function getUserString() {
  return doXhr("/user.json");
}

getUserString().addEventListener("progress", function (prog) {
  // good
});

function getUserObj() {
  return doXhr("/user.json").then(JSON.parse);
}

getUserObj().addEventListener("progress", function (prog) {
  // lost the progress!! events never fired :(
});

[jakearchibald]

I seeeeeee. So this new progress callback thing will go through the chain until it reaches a handler?

[domenic]

Those are kind of the semantics we've settled on for Q, and probably for Promises/A+. There's also questions about whether and how to allow transforming of the progress value (e.g. a progress handler could take decimals as input and output formatted percentages), what to do if the handler throws an exception, how/if to allow handlers to stop progress propagation, and what returning a promise from a progress handler does (if anything).

[domenic]

Also, whether progress events are delivered after a promise is fulfilled or rejected.

[DavidBruant]

For that matter, there is already something related to progress in the repo. Syntax would be:

doItAsyncWithProgress(...).
  progress(function(progressValue) { ... }).
  then(onaccept, onreject);

So no need to inherit from EventTarget in that situation.