> if used when cancelable is true if used when cancelable is NOT true, so throw if non cancelable
On Tue, Aug 4, 2015 at 6:32 AM, Andrea Giammarchi < [email protected]> wrote: > my proposal doesn't make abortability accidental, only promises that has > passed through their initialization the callback would be cancelable,and > this could be reflected through a `.cancelable` property. We could have > `.abort()` throwing if used when cancelable is true ( or not > undefined for backward compatiblity sake ) > > The only problem I see with my proposal is thay purists would never > accept cancel-ability in first place, and pragmatists would never find out > what should be the behavior once aborted 'cause Promise can only reject and > never be ignored. > > So the TL;DR is that I don't see cancel-able promises becoming reality at > any point in these days, I rather would think from scratch something better > ( Task ? ) and leave Promises the way these are, hoping standard bodies > will just stop putting/using them for everything asynchronous that might > take more than 10ms and **should** be cancelable. > > I'm the first one that want them cancelable, and at this point, after > months of discussions, the one that also doesn't see that as a solution. > > Best Regards > > > > On Tue, Aug 4, 2015 at 1:27 AM, Glen Huang <[email protected]> wrote: > >> @Andrea @Yad >> >> The only thing I'm not sure about is this "some promises have the abort >> ability, some don't" design. It might seem clear when you first create that >> promise, but it gets messy when you start to pass that promise around. It's >> very easy for some function to accidentally have the ability to abort() >> where it shouldn't. >> >> >> On Aug 4, 2015, at 1:19 AM, Andrea Giammarchi < >> [email protected]> wrote: >> >> not so different from what I've proposed already, except it looks ugly >> with a `self` at the end, and it's based on runtime method attachment that >> could happen at any time or mislead, or forget to invoke reject etc etc ... >> I will try to stay away from this thread 'cause I've already talked as much >> as I could about this topic but my proposal was this one: >> >> ```js >> var p = new Proomise((resolve, reject, fnIfAborted) => { >> let timer = setTimeout(resolve, 3000, 'All Good'); >> >> // **only** if fnIfAborted is invoked here >> // the promise will be cancelable, otherwise it cannot >> // be cancelable later on, and it's not possible >> // to even invoke fnIfAborted later on or asynchronously >> // this is the best I could think to make the contract as simple as >> possible >> fnIfAborted(function () { >> clearTimeout(timer); >> }); >> }); >> ``` >> >> Once established that the user that created the Promise is the only one >> capable of deciding if that could be cancelable or not, there's no way >> anything else could interfeer with that cancelability, and the promise can >> be passed around as cancelable, or simply wrapped through another non >> cancelable promise. >> >> This gives the promise creator the ability to cancel it without exposing >> such ability to the outer world. >> >> The eventual `p.abort()` if executed after the promise has been >> resolved/rejected will **not** invoke the `fnIfAborted` internally passed >> callback. >> >> Reasons such callback must be defined in the Promise scope is because >> only there there would be eventually the ability to resolve, reject, or >> abort the operation. >> >> It's simple, it's probably a bit ugly, but it's there to solve edge cases >> ( basically all network related cases or every case that might take long >> time and the user, or even the developer, might get border and would like >> to do something else instead of wasting resources ) >> >> >> >> >> Best Regards >> >> >> >> >> >> >> On Mon, Aug 3, 2015 at 7:08 AM, Yad Smood <[email protected]> wrote: >> >>> I have thought about something similar before, and used it in one of my >>> libs. Recently, I have come up another idea, it was already implemented on >>> Yaku: >>> >>> let Promise = require('yaku') >>> // The `self` is the instance of the newly created promise.let p = new >>> Promise((resolve, reject, self) => { >>> let tmr = setTimeout(resolve, 3000) >>> >>> let self.abort = () => { >>> clearTimeout(tmr) >>> reject(new Error('abort promise')) >>> } >>> >>> }) >>> >>> p.abort() >>> >>> The origin post is here: >>> https://github.com/promises-aplus/cancellation-spec/issues/16. >>> >>> what do you think about it? >>> >>> 2015年8月3日(月) 8:43 Glen Huang <[email protected]>: >>> >>>> I was discussing with Jake Archibald about cancelable promises the >>>> other day. I was trying to convince him promise.cancel() might not be a >>>> good idea. But that conversation unfortunately leans more towards on how >>>> the abort API should be exposed on fetch. I did provide some thoughts on >>>> that topic, and think the abort API represents a strong use case for >>>> cancelable promises. But I feel what's more important is the underlying >>>> control flow design. >>>> >>>> So I would like to offer my proposal of cancelable promises here, and >>>> would like to ask if you think it's a good idea, or if promise.cancel() is >>>> actually a good idea and my understanding of promises is flawed. >>>> >>>> I think that promises should be an observation API. In other words, it >>>> should be kept as one-way communication. This keeps promises simple and >>>> easy to reason about. >>>> >>>> When we talk about cancelable promises, what we really want is the >>>> ability to: >>>> >>>> 1. abort the action that the root promise observes. >>>> 2. let child promises show disinterest on the result of that action >>>> >>>> With the premise that promises should be one-way communication, it's >>>> clear that #1 should be achieved with a separate API. For example: >>>> >>>> ``` >>>> let query = queryDB(sql); >>>> query.done.then(data => console.log(data)); >>>> query.abort(); >>>> ``` >>>> >>>> This means you need to have access to that separate API in order to >>>> abort the action, instead of just the promise. >>>> >>>> And abort() rejects the root promise with a special error object, if >>>> it's pending. >>>> >>>> This also means the abort API doesn't have to be universal. Each action >>>> initiator can design their own APIs to abort that action. >>>> >>>> And correspondingly, to create a "cancelable promise" with the Promise >>>> constructor, it can be as simple as: >>>> >>>> ``` >>>> function doAction() { >>>> let abort; >>>> let done = new Promise((res, rej) => { >>>> asyncAction(res, rej); >>>> abort = () => rej(new AbortError()); >>>> }); >>>> return {done, abort}; >>>> } >>>> ``` >>>> >>>> For #2, I propose we add a method to Promise.prototype that undos >>>> .then() (probably also a sugar to undo .catch()) like removeEventListener >>>> undos addEventListener. For example. >>>> >>>> ``` >>>> let query = queryDB(sql); >>>> let updateView = data => render(data); >>>> let log = data => console.log(data); >>>> query.done.then(updateView).then(log); >>>> query.done.ignore(updateView); // deregister callback, updateView and >>>> log will never be called >>>> setTimeout(() => { >>>> query.done.then(updateView); // unless callback is registered >>>> again >>>> }, timeEnoughForQueryToFinish); >>>> ``` >>>> >>>> You can think it as that each promise keeps a list of its child >>>> promises, when the same callback is passed to .ignore() it sets a flag on >>>> the corresponding child promise so that when itself resolves/rejects, it >>>> won't pass that state to that child promise, unless that the same callback >>>> is later registered again. >>>> >>>> What do you think of this design? Do you think it covers all of your >>>> use cases for cancelable promises? >>>> >>>> I have to give credit for Kyle Simpson and Jake Archibald for this >>>> idea. Kyle's opposition of sending signal back to the promise vendor, and >>>> Jake's argument that we need a way to let an observer signal disinterest >>>> greatly clarifies my understanding of promises. >>>> >>>> I guess someone has probably expressed this idea somewhere in some way >>>> (or in some libraries). Sorry if I missed that. >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
