W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Cancellation architectural observations

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 2 Mar 2015 16:08:51 -0800
Message-ID: <CAAWBYDCtDvpiTH_TAsDC6WQuE2vpGTYUs5fVQxd4pjbwFSAUMQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Dean Tribble <tribble@e-dean.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Mon, Mar 2, 2015 at 3:52 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> So I think I'm persuaded by the argument that as long as an API
> returns a Promise, there is no way that we can put a
> cancellation/result-ignoring/close() API on that Promise. It seems to
> simply break the Promise contract.
> Instead we'd need to return some object which allows us to track
> consumers. I.e. where if you call a .then-like function, you prevent
> anyone else from doing so. And if you want to enable others to consume
> the result, you have to first fork the result and then call the
> .then-like function on your fork.
> Unfortunately that .then-like function probably can't be called "then"
> given the elevated status that Promises has given that function name.

This was the approach I was angling for early in the FetchPromise
thread at <https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75302002>;
I originally proposed that .then() always return a vanilla Promise,
and a separate method (I proposed .pipe()) do a chain that maintained
the cancellability (triggering refcounting and such).

Received on Tuesday, 3 March 2015 00:09:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC