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

RE: Future cancellation

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Wed, 1 May 2013 18:23:24 +0000
To: 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: <B4AE8F4E86E26C47AC407D49872F6F9F7EF66EE2@BY2PRD0510MB354.namprd05.prod.outlook.com>
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.
Received on Wednesday, 1 May 2013 18:23:59 UTC

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