Re: Promises as Cancelation Tokens

Since checking `promise.state` is synchronous, we may as well just write a synchronous Cancel class instead: ```js class CancelError extends Error { /* ... */ } class Cancel { constructor() { this.requested = false } request() { this.requested = true } throw() { throw new

Re: Promises as Cancelation Tokens

Cool, yeah, the reveal pattern would indeed be a good way to guard against unwanted/unexpected cancels. ```js class Cancel { constructor(executor) { this._requested = false executor(() => this._requested = true) } get requested() {return this._requested} throw() {

Re: Promises as Cancelation Tokens

> > Since checking `promise.state` is synchronous, we may as well just > write a synchronous Cancel class instead: > Right - see upthread. You do need some kind of callback method, though, like `whenCancelled(callback)`. > class Cancel { > constructor() { this.requested = false } >

Re: Promises as Cancelation Tokens

> > We have pretty sound cancellation semantics in bluebird 3. > Cool, I'm aware that cancellable promises have been explored in depth. I'd prefer to keep this thread focused on cancellation tokens though, and avoid comparisons. ___ es-discuss mailing

Re: Promises as Cancelation Tokens

> > The best approach in cases like this is to avoid the word altogether. > The fact that there's confusion at all means people will mess it up > and get annoyed, even if there's a "winner" in overall usage. > Hmmm... Maybe class CancelToken { constructor(init); get

Re: Promises as Cancelation Tokens

We have pretty sound cancellation semantics in bluebird 3. http://bluebirdjs.com/docs/api/cancellation.html Handles multiple subscribers soundly. Solves the common use cases pretty well - has absolutely zero magic and pretty simple semantics. They work with .all and .race too. We have had a

Re: Promises as Cancelation Tokens

> Cool, I'm aware that cancellable promises have been explored in depth. I'd prefer to keep this thread focused on cancellation tokens though, and avoid comparisons. Cool, re-reading the discussion you asked for this in the first message - I apologize for missing it. I think using promises as

Re: Promises as Cancelation Tokens

> We could use a promise subclass as the cancellation token, but then tokens (and their constructor) would inherit things that really don't make sense, like "CancelToken.resolve" and "CancelToken.prototype.catch". Generally I dislike inheritance. I was merely saying it's an option. I favor

Re: Promises as Cancelation Tokens

> > I think using promises as tokens would be problematic. It would have > several issues: > Agreed with all of those. It's also important to keep in mind that promises can be subclassed so it's > fine to add properties to them if used for a specific purpose like > cancellation. > We could use

RE: Promises as Cancelation Tokens

This gist contains the TypeScript declarations for the version of CancellationToken I’ve been using for a number of small projects. The basic API shape is: ```ts class CancellationTokenSource { constructor(linkedTokens?:

Re: Promises as Cancelation Tokens

>From experience, I'm very much in favor of the cancellation token. Though promises provide a good inspiration for cancellation, they don't quite fit the problem directly. The approach has been explored, though the details are not published. I implemented cancellation for the Midori system.

Promises as Cancelation Tokens

I'm interested in exploring the idea of using an approach similar to .NET's cancelation tokens in JS for async task cancelation. Since the cancelation "flag" is effectively an eventual value, it seems like promises are well-suited to modeling the token. Using a promise for a cancelation token

Re: Promises as Cancelation Tokens

> throw() { throw new CancelError() } > This should be `throwIfRequested` I think, e.g. throwIfRequested() { if (this._requested) throw new CancelError(); } } > What would be the recommended way of keeping the internal state > private? With a WeakMap? >

Re: Promises as Cancelation Tokens

On Mon, Jan 4, 2016 at 9:01 AM, Domenic Denicola wrote: > From: Kevin Smith [mailto:zenpars...@gmail.com] > >> And what's the deal, is it canceled or cancelled? : ) > > This is kind of the worst. Previous discussion at >

Re: Promises as Cancelation Tokens

> > I am also unsure when .whenCanceled is necessary > Maybe in the case where you have a promise-returning function and you want to reject the returned promise upon cancellation. function delayWithCancel(ms, cancelToken) { return new Promise((resolve, reject) => {

Re: Promises as Cancelation Tokens

I agree that without synchronous inspection cancellation tokens become very hard to deal with as you may be queued for a long time prior to cancellation on the event loop, and then the operation is cancelled while you are waiting to check for cancellation. Is there a reason to use a Promise as the

Re: Promises as Cancelation Tokens

And what's the deal, is it canceled or cancelled? : ) On Mon, Jan 4, 2016 at 11:30 AM Kevin Smith wrote: > Is there a reason to use a Promise as the cancellation token, rather than >> have something that is synchronously inspectable? >> > > The only real downside of

RE: Promises as Cancelation Tokens

In general I agree that there is a nice conceptual symmetry, but IMO the day-to-day impedance mismatch would be simply too great. Compare: ```js async function f(cancelationToken) { cancelationToken.then(() => console.log("FYI you have been canceled")); await

Re: Promises as Cancelation Tokens

> > Is there a reason to use a Promise as the cancellation token, rather than > have something that is synchronously inspectable? > The only real downside of coming up with a new interface is that we have to standardize it. : ) It's a core protocol. I agree that using a promise directly would

RE: Promises as Cancelation Tokens

From: Kevin Smith [mailto:zenpars...@gmail.com] > And what's the deal, is it canceled or cancelled?  : ) This is kind of the worst. Previous discussion at https://github.com/promises-aplus/cancellation-spec/issues/4. Data seems to favor cancelled: -