Cancelable promises proposal

[Isiah Meadows]

Am I the only one that sees this concept best left as a user Promise
subclass? Especially since I'm still seeing some disagreement on even what
the problem is that's needing solved.

On Sat, Aug 8, 2015, 05:02 Glen Huang <curvedmark at gmail.com> wrote:

> Note that when you attach a reaction (through the `.then()` method) to a
> promise that was resolved several minutes ago, the reaction will trigger:
> you have to somewhat stretch you mind in order to call that "reacting to
> state change".
>
>
> What attaching callbacks through `.then()` really does is to create a new
> promise and attach it to the parent promise. The reaction lives in the new
> promise, and every new child promise without a parent promise is equivalent
> to having a pending parent promise. So when you attach that new promise to
> a resolved parent promise, I think it's reasonable to say that, from the
> reaction's point of view, the parent promise's state has changed.
>
> As I understand, promises are ideal for requesting and transmitting data
> without having to care much when the data is available
>
>
> IMHO, that's promises's goal. How does it archive that? By reacting to
> parent's promise state change, which is really just a event. The only thing
> special about promises is that when you add event listeners, a new promise
> containing those listeners are returned, and the events are only filed once
> for each promise. Getting the data is like reading event.data.
>
> If you use promises for asking for data, "cancelling" is naturally akin to
> "reject with an abort signal as reason".
>
>
> Yes, looks like akin, but is actually totally different. cancelling sends
> signals back to parent, rejecting sends signals down to children. The
> symmetry can be misleading. Able to sending signals in both directions
> greatly complicates the design of promises with no obvious benefits. What
> I'm saying is that to archive the goals that you want from cancelling, you
> actually don't need the ability to send signal upwards. You don't need to
> open that can of worms.
>
> The child promise that want to show disinterest should just settle itself
>
>
> Are you talking about this pattern:
>
> ```
> let parentPromise = asyncAction();
> let cancel;
> let tmpPromise = new Promise((res, rej) => {
>   cancel = () => rej(new AbortError());
> });
> let childPromise = Promise.race([parentPromise.then(...), tmpPromise]);
> childPromise.cancel = cancel;
> ```
>
> This is still one way communication. So does it mean that you agree
> promises should be kept that way?
>
> And basically you are giving promises the ability to resolve / reject
> themselves after they are created. Let me rewrite previous example with
> more familiar APIs:
>
> ```
> let parentPromise = asyncAction();
> let childPromise = parentPromise.then(...);
> childPromise.reject(new AbortError()); // don't care about parent promise,
> let's reject the childPromise
> ```
>
> This also means a grand child might have to differentiate from an abort
> rejection from a root promise or an ancestor promise, once you encourage
> this pattern.
>
> Also, with the ignoring parent state change design, its possible to make a
> promise be interested its parent's state change again after it has shown
> disinterest. I don't think it's possible if you expose resolve / reject on
> created promises.
>
> On Aug 8, 2015, at 3:13 AM, Claude Pache <claude.pache at gmail.com> wrote:
>
>
> Le 6 août 2015 à 04:20, Glen Huang <curvedmark at gmail.com> a écrit :
>
> promises are fundamentally about chaining data together, not about
> listening for events.
>
>
> IMHO, promises are more about reacting to state change and pass down that
> reaction. And the reaction I'm proposing to add is "no reaction will be
> passed down".
>
>
> Note that when you attach a reaction (through the `.then()` method) to a
> promise that was resolved several minutes ago, the reaction will trigger:
> you have to somewhat stretch you mind in order to call that "reacting to
> state change".
>
> As I understand, promises are ideal for requesting and transmitting data
> without having to care much when the data is available (be it several
> minutes ago or several minutes later) — which would be managing an event.
> On the contrary, a "state change" sounds more like an event.
>
> The way you think of (and use) promises will influence the way you think
> what "cancelling a promise" and similar actions should do. If you use
> promises for asking for data, "cancelling" is naturally akin to "reject
> with an abort signal as reason".
>
> Now concerning your original case: "let child promises show disinterest on
> the result of that action". The child promise that want to show disinterest
> should just settle itself (for example reject itself with an abort signal,
> but the precise outcome may depend on the reason why you want to stop
> listening). That will give an appropriate signal to downstream clients, and
> that will prevent itself from receiving messages from upstream (because a
> promise cannot be settled more than once). — (True, the `.then()` method
> doesn’t produce a promise that could be settled prematurely: you have to
> construct it manually. I leave that as an exercise to the reader.)
>
> —Claude
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150809/a89541d9/attachment.html>