canceling should **not** pass through any errorback chain... Canceling is like an explicit abort on xhr ... Not an error, not a fulfillment, it's a third state: cancelled
-----Original Message----- From: "C. Scott Ananian" <[email protected]> Sent: 27/10/2014 19:39 To: "Andrea Giammarchi" <[email protected]> Cc: "Tab Atkins Jr." <[email protected]>; "Mark S. Miller" <[email protected]>; "Domenic Denicola" <[email protected]>; "Mark Miller" <[email protected]>; "es-discuss list" <[email protected]> Subject: Re: Promise-returning delay function There's already a way to cancel a Promise -- use its `reject` function. eg. ```js var reject; Promise.delay(100/*ms*/).then(function() { reject(new Error('took too long')); }); return new Promise(function(resolve, _reject) { reject = _reject; resolve(doSomethingTimeConsuming()); }); ``` There's no need to rethink or redesign anything. See https://github.com/cscott/prfun#promisetimeoutint-ms--string-message--promise for a nice example, borrowed from `bluebird`. --scott On Mon, Oct 27, 2014 at 3:20 PM, Andrea Giammarchi <[email protected]> wrote: > I thought promises were introduced to simply the "whenever it happens" > pattern ... using a delay seems a pretty pointless feature to me and > setTimeout worked so far (15 years?) pretty well and it is cancelable. > > Regardless delay though, canceling, beast or not, should be considered > before all these changes will make it "impossible" to implement, IMO > > On Mon, Oct 27, 2014 at 2:52 PM, Tab Atkins Jr. <[email protected]> > wrote: >> >> On Mon, Oct 27, 2014 at 3:21 AM, Andrea Giammarchi >> <[email protected]> wrote: >> > Not sure if discussed already but I believe `.cancel()` or >> > `.forgetAboutIt()` mechanism should be proposed before introducing any >> > `.delay()` >> > >> > Promises often put developers in unmanaged roads where things keep being >> > "forgotten" and/or impossible to drop without ending up in the next >> > chain, >> > undesired, or the error stack, even less desired. >> > >> > What I mean is that if `setTimeout` is a desired pattern to replicate >> > through `.delay(ms)`, but I really don't understand why that would be a >> > desired pattern at all, `clearTimeout` functionality should be >> > considered as >> > well. >> > >> > A generic `.cancel()` would be most likely the easier approach but it >> > should >> > be implemented upfront. >> >> Cancelable promises are a completely different beast; it's not just a >> matter of adding a new method to Promise.prototype, it's changing the >> data structure pretty fundamentally. Suddenly you have a new >> value-affecting capability, but it's exposed outside of the >> constructor. You need to be able to react to a cancellation, so you >> can actually cancel the work being done, and possibly resolve the >> promise to some default value (or error). >> >> A promise that auto-resolves after a timeout, on the other hand, is a >> straightforward utility function of obvious usefulness, and requires >> no additional work: >> >> Promise.delay = function(ms) { >> return new Promise(function(r) { setTimeout(r, ms); }); >> } >> >> (Not tested, but this should be approximately right.) >> >> ~TJ > > > > _______________________________________________ > 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
