Extensibility for .then()?

[slightlyoff]

It turns out that allowing extensibility via the callbacks parameter only exacerbates the lack of it in .then()'s signature. E.g., if you add a progress callback to a subclass, how does one register to hear about it in .then()? Today, you fight over a 3rd positional parameter, which is as inelegant as the same fight in the API of Future.

One idea sparked from coversation with @jakearchibald is to allow a mirroring bag of callbacks in the signature of .then().

You might then write something like:

f.then({ accept: function(v) { ... },
         reject: function(e) { ... },
         progress: function(...) { ... },
         // other extensions here...
});

[slightlyoff]

@jakearchibald objects to this (in conversation) because the additional callback isn't an "end of play" event, whereas accept() and reject() callbacks are.

He suggests instead that these futures should have a .on() that is like addEventListener() but which is chainable, returning the Future instance itself. I like this a lot.

Thoughts? @domenic @arv @annevk?

[domenic]

I think addEventListener is a fine interface for progress or other events already; on is part of a larger debate on public-webapps if I recall. In other words, I'm not sure it's a futures spec's place to define on as a shorter-to-type, returning-this version of addEventListener.

I agree that accept/reject are primary and having them be the two positional parameters to then is important.

[slightlyoff]

It looks like we might be able to have addEventListener become chainable. It returns nothing right now:

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget-addEventListener

We'd have to test what it breaks in Canary/Dev for a while, but unless @annevk objects, we can start small by having a sub-interface of EventTarget for Future which specifies that addEventListener() returns the EventTarget itself.

[jakearchibald]

The alternative is to wait for .on to arrive. But yeah, anything that isn't a Future end point should be handled by events.

[slightlyoff]

I'm honestly having a hard time imagining why we won't unify the return types between addEventListener and on once it's decided. Will jump into that discussion with @annevk, though. I think we have a resolution to this, despite not knowing how it'll actually play out.