W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

RE: Future cancellation

From: Ron Buckton <rbuckton@chronicles.org>
Date: Wed, 1 May 2013 19:03:34 +0000
To: Domenic Denicola <domenic@domenicdenicola.com>, Tab Atkins Jr. <jackalmage@gmail.com>, Bill Frantz <frantz@pwpconsult.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, Brendan Eich <brendan@mozilla.com>, es-discuss <es-discuss@mozilla.org>
Message-ID: <33D2646B20374248B7CAA8F25919AAFC427641F0@BY2PRD0111MB494.prod.exchangelabs.com>
This is where something like an external cancellation source could be more effective:

```js
function getUser1(cancelToken) {
  return doXHR("/user.json", cancelToken);
}

function getUser2(cancelToken) {
  // immediate result, no need for cancellation
  return { "name": "domenic" };
}

function getUser3(cancelToken) {
  return doXHR("/user.json", cancelToken).then(function (user) {
    user.metadata = "<meta> tags are old school";
  });
}

var cts = new CancellationTokenSource();
var usersF = Future.every(getUser1(cts.token), getUser2(cts.token), getUser3(cts.token));
usersF.done(function(users) {
});
cts.cancelAfter(5000); // timeout after 5 seconds.
```

Rather than subclassing Future, you use an external source provided by the caller to manage cancellation. Now it doesn't matter whether either of the 3 methods have a return value that supports cancellation, and if the caller doesn't need to cancel, it can provide null or undefined.

Ron

> -----Original Message-----
> From: es-discuss-bounces@mozilla.org [mailto:es-discuss-
> bounces@mozilla.org] On Behalf Of Domenic Denicola
> Sent: Wednesday, May 1, 2013 11:23 AM
> To: Tab Atkins Jr.; Bill Frantz
> Cc: public-script-coord@w3.org; Brendan Eich; es-discuss
> Subject: RE: Future cancellation
> 
> From: Tab Atkins Jr. [jackalmage@gmail.com]
> 
> > I think you're making this far too complicated.  It's much simpler than this:
> 
> I disagree. An abstraction boundary gets broken. Consider:
> 
> ```js
> function getUser1() {
>   return doXHR("/user.json");
> }
> 
> function getUser2() {
>   return { "name": "domenic" };
> }
> 
> function getUser3() {
>   return doXHR("/user.json").then(function (user) {
>     user.metadata = "<meta> tags are old school";
>   });
> }
> ```
> 
> Here, `getUser1()` returns a cancellable promise, but `getUser2()` does not,
> even though they should have the same semantics. Worse, `getUser3()` isn't
> cancellable, even though it was originally derived from an XHR. Trying to fix
> the `getUser3()` case is what takes you down the slope of complex additional
> semantics.
> 
> Much better would be if a hypothetical future XHR utility returned a `{
> promise, abort }` object, with no logical connection between the `abort` and
> the `promise` (besides maybe rejecting the promise with a well-known
> error). This seems much better than trying to make a general cancellation
> concept for promises and overloading them with additional semantics about
> the operation being performed.
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
Received on Wednesday, 1 May 2013 19:04:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC