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

Re: Future cancellation

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 1 May 2013 13:37:31 -0700
Message-ID: <CAAWBYDAOuFZC2qQvkiynL-YqHYs6dkf5_yYKvA6cg_YzAfb8jA@mail.gmail.com>
To: Bill Frantz <frantz@pwpconsult.com>
Cc: Brendan Eich <brendan@mozilla.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Wed, May 1, 2013 at 1:29 PM, Bill Frantz <frantz@pwpconsult.com> wrote:
> On 5/1/13 at 11:13 AM, jackalmage@gmail.com (Tab Atkins Jr.) wrote:
>> I think you're making this far too complicated.  It's much simpler than
>> this:
>> 1. XHR is a very reasonable API to Future-ize.
>> 2. XHRs are cancellable.
>> 3. Ergo, we should have a cancellable Future subtype.
> Why make it more complex than necessary. While a XHR implementation may wish
> to add a cancel operation, JS is a broader language than just the web. There
> are use cases that don't need cancel and they should not have to pay the
> costs of the additional communication paths that cancel will require.
> With a simple promise, others can build objects which use the promise as an
> internal component and provide cancel or other useful operations. Leaving
> the implementations of these other operations to libraries will allow
> experimentation to proceed standardization.

Ah, I'm not proposing that we augment the base Future class with
cancellation properties.  I explicitly used the term "subtype" in the
quoted bit above.  *Some* of Ron's suggestions were to augment the
base Future class, but not all of them, and several other people
pushed back on that.

Received on Wednesday, 1 May 2013 20:38:19 UTC

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