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 11:13:46 -0700
Message-ID: <CAAWBYDD0RC7J1QmDzjJj_OmGMKsiTsc_5-gMbb04UcEroUCioA@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 11:04 AM, Bill Frantz <frantz@pwpconsult.com> wrote:
> On 5/1/13 at 7:54 AM, jackalmage@gmail.com (Tab Atkins Jr.) wrote:
>> On Wed, May 1, 2013 at 5:50 AM, Bill Frantz <frantz@pwpconsult.com> wrote:
>>> On 4/30/13 at 11:04 PM, jackalmage@gmail.com (Tab Atkins Jr.) wrote:
>> ...
>>>> 1. Some promises are holding onto resources (locks, network
>>>> connections, cpu time) which will be disposed of when they're
>>>> finished.
>>> I think this statement is wrong. Promises don't hold resources. They are
>>> a
>>> placeholder for a value to be provided later. Perhaps the computation
>>> which
>>> may provide the value at some future time holds a resource, or the
>>> computation which will consume the value when it is resolved holds a
>>> resource (generally a poor programming practice), but the promise itself
>>> doesn't hold resources.
>> Semantics.  ^_^  The promise can represent a computation, which can
>> hold some releasable resources.
> To my mind this is an important distinction. The promise does not represent
> the computation. It represents the result.
> Any representation of the computation itself bring in a whole lot baggage
> which includes, the problem of managing distributed computation in the cloud
> plus a lot of other issues. Dragging this stuff into the base level of a
> programming language is a bad crossing of abstraction levels.

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.

Received on Wednesday, 1 May 2013 18:14:33 UTC

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