Re: Future cancellation

To be honest, I haven't yet seen an explanation of why 'I no longer have
any need for the contents of this future' is not tied to the underlying
semantics of a future. Where else would it go? I agree with you that
complicating a primitive in order to support a small subset of use cases is
undesirable, and it does seem like perhaps end-user subclassing of
futures/promises addresses all these use cases. But it is troubling to me
to consistently see real use cases dismissed as somehow unworthy of
consideration because they do not meet some unspecified semantic bar.

And to restate some points that have cropped up in the thread multiple
times so far, since they are relevant to your arguments:

Future cancellation is not the same as task cancellation; it is different.
I would agree with any suggestion that using the names 'cancel' or 'abort'
probably leads people to assume that they are the same. I prefer the term
'disposal' but that is perhaps overly .NETty and implies things that do not
apply to JS.

Layering disposal onto a promise from the outside is fine, but requires
that all consumers of an API have prior knowledge of the way the API is
implemented; that is, the API author has to expose disposal beforehand
(even if it is not used) and the consumer has to know that it is needed.
This exposes whether or not disposal is *actually used* by an
implementation when it should be an implementation detail. Much like how -
to pick an arbitrary example - finally blocks in a generator should run if
you enumerate the generator with for-of, it is desirable to have a
universal way to indicate that a future's value is unneeded by a single
consumer such that any given API implementer can extend their
implementation seamlessly to abort operations that are no longer needed.
This allows significant changes to the backend of an operation (caching,
batching, etc) without changing the public API. (Note that you can probably
address this with a Future subclass instead of baking disposal into Future
itself, or by exposing some sort of public function that you can call on a
future to indicate that you are done with it and making that function a
no-op for non-disposable futures. I don't have a strong opinion).

I'm fine with cancellation and progress being nuked from futures for
conceptual purity; simpler is probably better. But if you're going to kill
them, you should do it based on sound reasoning, otherwise they're just
going to keep cropping up again and again because people want them and will
probably not accept a justification that seems based on a misunderstanding
of their arguments.

Given the choice between explicitly not specifying disposal, and specifying
an 'encouraged way to do it' (i.e. via subclassing), I would also lean
towards the latter. That is, if you're going to say 'we don't need to spec
disposal', by demonstrating an incredibly easy way to do it via
subclassing, you address any arguments that it must be built into the
language or into DOM futures, and you demonstrate a pattern that is
expected to work based on the current spec.


-kg


On Tue, Apr 30, 2013 at 9:25 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> 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.
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>