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 04:25:27 +0000
To: Jonas Sicking <jonas@sicking.cc>, Ron Buckton <rbuckton@chronicles.org>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F7EF65FC2@BY2PRD0510MB354.namprd05.prod.outlook.com>
From: es-discuss-bounces@mozilla.org [mailto:es-discuss-bounces@mozilla.org] On Behalf Of Jonas Sicking

> It isn't actually surprising that the same issues arise. ProgressFuture basically delivers progress about an "operation" rather than a "result".

I agree. I think both progress and cancellation (of underlying operations) are attractive nuisances. They seem like they fit in well with the model, and would be useful for certain use cases. But they are actually very different, and not tied to the underling promise semantics at all—which are of a first class value representing a promised "result," as you put it, not representing an ongoing "operation."

I lean toward not specifying or including them at all. Although you can try to stuff them naively into the promise semantics, you end up needing to complicate the conceptual model in order to make them behave as you wish. As you point out, this is clearly visible with the various combinators. But it's also visible in basic semantic questions that arise: e.g. downward progress propagation/transformation, or the role of throwing inside a progress handler, or upward cancellation progagation/reaction, or downward cancellation forking, or the role of rejections in cancellation. You soon realize that you're trying to smush in semantics where they don't belong.

In other words, separate abstractions for cancellation or progress, unrelated to promises, seem best.
Received on Wednesday, 1 May 2013 04:26:02 UTC

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