Re: Promises: unhandled rejections and finally()

ack and make sure you understand what it is that triggers these errors. > Node triggers these errors when a promise object has been rejected but has > no handlers to do respond to the rejection. I forget exactly what point > Node checks for handlers these days, if that point is at the end o

Re: Promises: unhandled rejections and finally()

or handlers these days, if that point is at the end of the job > execution or on GC of promises now or what but that's not important for this > case. > > Let's look at your example. I'm also simplifying it to > ``` > var p = Promise.reject(789); > var one = p.final

Re: Promises: unhandled rejections and finally()

end of the job execution or on GC of promises now or what but that's not important for this case. Let's look at your example. I'm also simplifying it to ``` var p = Promise.reject(789); var one = p.finally(() => {}); var two = p.finally(() => {}); var three = p.finally(() => {}); ```

Promises: unhandled rejections and finally()

Hello, In node 12 as well as the latest Chrome and FF (all on macOS) I see the following: - var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); n(789); ==> produces 1 unhandled-rejection warning var y,n; var p = new Promise( (yy,nn) => { y=yy; n=nn } ); p.finally( () => {} );

Re: performance benchmark of async-design-patterns - recursive-callbacks vs. promises vs. async/await

Nice... And not really surprising. I am slightly surprised async/await is so close to promises. Which means that improving promises performance should probably be a priority. I still feel the easier to reason with code is well worth it, given many apps now scale horizontally. On Sun, Apr 29

performance benchmark of async-design-patterns - recursive-callbacks vs. promises vs. async/await

fyi, here are some benchmark results of nodejs' client-based http-request throughput, employing various async-design-patterns (on a 4gb linode box). overall, recursive-callbacks seem to ~15% faster than both async/await and promises (~3000 vs ~2600 client-http-request/s). ```shell

Re: Proposal: Conditional `catch` in Promises

I agree this isn't ideal (it's a design hack that wasn't very well thought through on the part of Bluebird IMHO), but not on your justification (which comes across as borderline off-topic). Most complex exception handling with promises are effectively handled using async/await, but I agree

Re: Proposal: Conditional `catch` in Promises

> On 26 Apr 2018, at 12:08 PM, Ayush Gupta wrote: > > It might be worth **explicitly** mentioning that it's not about types either, > the benefit with using functions as the filter is that we can tackle a lot of > cases. Consider this: > > ```js > return somePromise >

Re: Re: Proposal: Conditional `catch` in Promises

It might be worth **explicitly** mentioning that it's not about types either, the benefit with using functions as the filter is that we can tackle a lot of cases. Consider this: ```js return somePromise .catch((reason) => reason instanceof ValidationError, reason =>

Re: Re: Proposal: Conditional `catch` in Promises

What do you mean by "approach TypeScript"? Do you mean propose this feature to the TS team? TS is not about new language features (with a few exceptions). It's about typing. They're quite careful about not forking the language. > Not sure if that supports typed errors No, it doesn't. Bob On

Re: Re: Proposal: Conditional `catch` in Promises

Maybe approach typescript on this one... Not sure if that supports typed errors like C# does, but would probably suit you well. On Wed, Apr 25, 2018, 08:31 Isiah Meadows wrote: > I'd still prefer we wait until pattern matching [1] gets addressed first, > then tackling

Re: Re: Proposal: Conditional `catch` in Promises

I'd still prefer we wait until pattern matching [1] gets addressed first, then tackling this. Error types are represented about 50 different ways in JS, with subtyping only being one (used by the standard kind of). Node appends an `err.code`, and the DOM adds a similar type, just using a common

Re: Re: Proposal: Conditional `catch` in Promises

We could potentially provide the same functionality in `try/catch` by extending the signature of `catch` to ```js try { } catch(, ) { } ``` If `` evaluates to truthy, invoke the `catch` block, otherwise don't. ___ es-discuss mailing list

Re: Proposal: Conditional `catch` in Promises

-try-catch [2]: https://esdiscuss.org/topic/filtered-promise-catch On Tue, Apr 24, 2018 at 10:35 AM, Ayush Gupta <ayushg3...@gmail.com> wrote: > I propose that in `Promises`, we accept another function which returns a > `boolean` as an argument to `catch`. It will enable us to write cod

Proposal: Conditional `catch` in Promises

I propose that in `Promises`, we accept another function which returns a `boolean` as an argument to `catch`. It will enable us to write code like this: ```js return somePromise .catch((reason) => reason instanceof ValidationError, reason => handleValidationError(reason)) //

Re: Cancel Promise pattern (no cancellable promises)

Jan 12, 2017 at 1:12 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > >> And that's why we're waiting on the next meeting to happen with notes >> posted, so we can figure out what to do next. It's likely to get discussed, >> especially considering the current s

Re: Cancel Promise pattern (no cancellable promises)

sted, so we can figure out what to do next. It's likely to get discussed, > especially considering the current situation and pressing need for it. > > On Thu, Jan 12, 2017, 13:27 Jordan Harband <ljh...@gmail.com> wrote: > >> The Cancellable Promises proposal itself is c

Re: Promises, async functions, and requestAnimationFrame, together.

Ah, I think the reason that this animation loop using promises works is because promise handlers resolve in the next microtask after the current macrotask. I believe that the animation frame fires in what is essentially a macrotask, then immediately after this macrotask the resolution

Re: Enable async/await to work on functions that don't just return promises.

b 27, 2017 at 12:41 AM, Isiah Meadows > <isiahmead...@gmail.com <mailto:isiahmead...@gmail.com>> wrote: > > May I add one more thing: the main topic this was about is adapting > > non-standard async APIs (like Node's error-first callback idiom) >

Re: Enable async/await to work on functions that don't just return promises.

On Mon, Feb 27, 2017 at 12:41 AM, Isiah Meadows <isiahmead...@gmail.com> wrote: > May I add one more thing: the main topic this was about is adapting > non-standard async APIs (like Node's error-first callback idiom) to the land > of promises. Async functions and iterators are in

Re: Enable async/await to work on functions that don't just return promises.

wrote: > May I add one more thing: the main topic this was about is adapting > non-standard async APIs (like Node's error-first callback idiom) to the > land of promises. Async functions and iterators are incredibly useful when > you're dealing with just promises, especially consuming the

Re: Enable async/await to work on functions that don't just return promises.

May I add one more thing: the main topic this was about is adapting non-standard async APIs (like Node's error-first callback idiom) to the land of promises. Async functions and iterators are incredibly useful when you're dealing with just promises, especially consuming them, but this is about

Re: Enable async/await to work on functions that don't just return promises.

Codefined, just out of curiousity, do you have anything to do with this proposal that got announced today ? Or is it just a coincidence? :) ​ On Sun, Feb 26, 2017 at 3:07 PM Dean Tribble wrote: > Should `callee()` be asynchronous

Re: Enable async/await to work on functions that don't just return promises.

> > Should `callee()` be asynchronous here? To my mind, no, it shouldn't. > Every single line here is synchronous, so the function itself should surely > be synchronous. Shouldn't functions that may not have `await` in them, but > instead that are actually asynchronous and hence use the `async

Re: Enable async/await to work on functions that don't just return promises.

A very interesting read indeed Alexander!  Gave me a new example to give when people ask what the worst code I'd ever seen was: Promise DoSomething(Promise cmd) { return cmd.WhenResolved( s => { if (s == "...") { return DoSomethingElse(...).WhenResolved( v => { return ...; }, e => { Log(e);

Re: Enable async/await to work on functions that don't just return promises.

t; wrote: > > I'll be interested to see what you guys consider the > advantages/disadvantages of this method, which I hope to be "the middle > between two ends" on whether to go fully into promises or fully into > co-routines. Neither of which are in my opinion the optimal stance

Re: Enable async/await to work on functions that don't just return promises.

efined <codefi...@debenclipper.com [mailto:codefi...@debenclipper.com]> wrote: I'll be interested to see what you guys consider the advantages/disadvantages of this method, which I hope to be "the middle between two ends" on whether to go fully into promises or fully into co-routi

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 5:30 PM, Codefined <codefi...@debenclipper.com> wrote: > I'll be interested to see what you guys consider the > advantages/disadvantages of this method, which I hope to be "the middle > between two ends" on whether to go fully into promises or

Re: Enable async/await to work on functions that don't just return promises.

e needed above the `c()` function, unlike in the previous proposal iteration. I'll be interested to see what you guys consider the advantages/disadvantages of this method, which I hope to be "the middle between two ends" on whether to go fully into promises or fully into co-rou

Re: Enable async/await to work on functions that don't just return promises.

await/async are de-facto co-routines. await/async will infect all code by necessity of software engineering. At which point they're actual co-routines, implemented badly, without a proper API. On Sun, Feb 26, 2017 at 3:26 PM, Jerald Cohen wrote: > Florian, > > You sure

Re: Enable async/await to work on functions that don't just return promises.

Florian, You sure you're not just adding more complexities to a language with features that were _meant_ to remove such complexity? Codefined's solution to me seems to be the one with the least amount of added techniques in order to learn. Although I understand how co-rountines are awesome,

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 2:51 PM, Codefined wrote: > What I feel we need is some way of making an asynchronous function > "appear" to be synchronous. > That's what co-routines are. Best practices for co-routines is usually to have some sort of API to spawn them (like

Re: Enable async/await to work on functions that don't just return promises.

Ah, that would indeed make sense.  What I feel we need is some way of making an asynchronous function "appear" to be synchronous.  Actually that's sort of what I expected async/await to do, but that only seems to affect where it's called, as opposed to the function

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 2:17 PM, Codefined wrote: > Because `d()` is no longer an asynchronous function, you can call it like > normal, surely? > Only async functions can await. Only await pauses execution to wait on async.

Re: Enable async/await to work on functions that don't just return promises.

I talk to gets stuck up on some part of it. Promises are bad, and mixing them with async/await is worse. Should never have been added to any kind of standard. async function asyncFunction() { let [err, data] = await asyncFunction() } function asyncFunction(){   return otherAsyncFunction(); } Even

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 2:08 PM, Jerald Cohen wrote: > (although, at the moment, I fail to see why one can't just use a normal > "return"). > You're probably unaware of this, but there is a fixation in this community, and many adjacent ones, that if you sprinkle syntax

Re: Enable async/await to work on functions that don't just return promises.

n't an argument. > > On Sun, Feb 26, 2017 at 12:05 PM, Alexander Jones <a...@weej.com> wrote: > >> Florian, you shouldn't pass the argument of explicit vs implicit >> coroutines off as being so simple. There are many compelling arguments for >> both! Please Google th

Re: Enable async/await to work on functions that don't just return promises.

I actually really like this idea. It reminds me of the C# syntax to try to accomplish the same thing. Although under the bonnet C# uses "tasks", which appear to be their form of promises, the surface code does look very similar, take for example: public async Task MyMethodAsync()

Re: Enable async/await to work on functions that don't just return promises.

, Codefined <codefi...@debenclipper.com> >> wrote: >> >> This seems to be so very confusing for anybody new studying this >> language, almost everyone I talk to gets stuck up on some part of it. >> >> Promises are bad, and mixing them with async/await is wor

Re: Enable async/await to work on functions that don't just return promises.

d <codefi...@debenclipper.com> > wrote: > > This seems to be so very confusing for anybody new studying this language, > almost everyone I talk to gets stuck up on some part of it. > > Promises are bad, and mixing them with async/await is worse. Should never > have been adde

Re: Enable async/await to work on functions that don't just return promises.

into a situation like this in your first program (for example, reading/writing to a file using promises).  Take: function asyncFunction() { return new Promise(resolve => { someAsync('data', (...args) => resolve(args)) }) } Here you have to explain the concept of returning a promise, anonymous functions,

Re: Enable async/await to work on functions that don't just return promises.

won't alleviate you of the need to learn promises anyways, and in general, when you're working with async code, you *should* learn the Promise APIs. Otherwise, `async` functions won't make much sense to you, and you're liable to forget an `await` when you needed one. 3. The concepts aren't

Re: Enable async/await to work on functions that don't just return promises.

On Sat, Feb 25, 2017 at 11:55 PM, Codefined <codefi...@debenclipper.com> wrote: > This seems to be so very confusing for anybody new studying this language, > almost everyone I talk to gets stuck up on some part of it. > Promises are bad, and mixing them with async/await is wors

Enable async/await to work on functions that don't just return promises.

promises in the first place.  Wouldn't it be so much more powerful to be able to use completely normal syntax, as you would in synchronous code as well as the option of promise chains? For example, take the following code snippet: async function asyncFunction() { return new Promise((resolve, reject

Re: Cancel Promise pattern (no cancellable promises)

wrote: > The Cancellable Promises proposal itself is currently withdrawn, but don't > forget that all of the previous discussion on cancellation in promises led > to that proposal. > > It would be shortsighted to pretend they don't exist, or that the spec > proposal won't matter forever t

Re: Cancel Promise pattern (no cancellable promises)

The Cancellable Promises proposal itself is currently withdrawn, but don't forget that all of the previous discussion on cancellation in promises led to that proposal. It would be shortsighted to pretend they don't exist, or that the spec proposal won't matter forever to any other cancellation

Re: Cancel Promise pattern (no cancellable promises)

Cancellable promises is dead. Please don't hijack this thread discussing them. Thanks, .: Jan-Ivar :. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Cancel Promise pattern (no cancellable promises)

of all affected promises, so potential api for overriding default cancellation delivery mechanism/"rail" (success/failure/cancellation) might exist still however I can not see them in bluebirdjs documentation. ___ es-discuss mailing list

Re: Cancel Promise pattern (no cancellable promises)

.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise#Parameters). But very different in a way how callbacks of "affected" promises should be treated. As I can understand from [bluebirdjs-cancellation]( http://bluebirdjs.com/docs/api/cancellation.html) article - on cancellation meth

Re: Cancel Promise pattern (no cancellable promises)

ad.interrupt()``)]( > https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt()), > assuming that "Thread" here can be "async stacktrace of promises", and > interrupt notification should be just forwarded to top entry > ([promise-executor]( > https://develop

Re: Cancel Promise pattern (no cancellable promises)

In general I thing it would be good to have something like [``java``(``Thread.interrupt()``)]( https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt()), assuming that "Thread" here can be "async stacktrace of promises", and interrupt notification should be j

Re: Cancel Promise pattern (no cancellable promises)

41 PM, Jan-Ivar Bruaroey wrote: This is an alternative to cancellable promises that relies entirely on existing JavaScript. I'm posting this here in hopes to bring the discussion back to practical use cases and minimal needs. Example: Here's a setTimeout wrapper with cancellation, using a regular promise as a

Re: Cancel Promise pattern (no cancellable promises)

On 10/31/16 2:39 PM, Herby Vojčík wrote: Jan-Ivar Bruaroey wrote: On 10/28/16 8:39 AM, Bergi wrote: Jan-Ivar Bruaroey wrote: If you try the fiddle - http://jsfiddle.net/jib1/jz33qs32/ - you'll see cancelling terminates the chain. If you intersperse non-cancellable operations, there'd be a

Re: Cancel Promise pattern (no cancellable promises)

Herby Vojčík wrote: Jan-Ivar Bruaroey wrote: On 10/28/16 8:39 AM, Bergi wrote: Jan-Ivar Bruaroey wrote: If you try the fiddle - http://jsfiddle.net/jib1/jz33qs32/ - you'll see cancelling terminates the chain. If you intersperse non-cancellable operations, there'd be a delay if cancel is

Re: Cancel Promise pattern (no cancellable promises)

Jan-Ivar Bruaroey wrote: On 10/28/16 8:39 AM, Bergi wrote: Jan-Ivar Bruaroey wrote: If you try the fiddle - http://jsfiddle.net/jib1/jz33qs32/ - you'll see cancelling terminates the chain. If you intersperse non-cancellable operations, there'd be a delay if cancel is detected during those.

Re: Cancel Promise pattern (no cancellable promises)

); especially when you'll need to nest that pattern. Instead, I'd just like to write promise() …chain… .then(callback, cancelToken) with the same behaviour. A crucial problem that promises don't solve is synchronous inspection. If my operation was cancelled, I'd like to know immediately (before

Re: Cancel Promise pattern (no cancellable promises)

maining chain. I'm not claiming it has utility, just avoiding inventing things. Perhaps: fetch("http://flo.ra/dailyflower.png;, {cancel: wait(5000).then(() => fetch("lily.png")}) A crucial problem that promises don't solve is synchronous inspection. If my operation was cancelled

Re: Cancel Promise pattern (no cancellable promises)

your feedback about using a regular promise as a cancellation token. A crucial problem that promises don't solve is synchronous inspection. If my operation was cancelled, I'd like to know immediately (before starting further work) about it, instead of waiting another tick to be notified.

Re: Cancel Promise pattern (no cancellable promises)

Likely this would be more convincing without a bug. Here is the correct wait function: let wait = (ms, cancel = new Promise(() => {})) => { let id, both = x => [x, x]; cancel.then(...both(() => clearTimeout(id))); return Promise.race([new Promise(resolve => id = setTimeout(resolve, ms)),

Cancel Promise pattern (no cancellable promises)

This is an alternative to cancellable promises that relies entirely on existing JavaScript. I'm posting this here in hopes to bring the discussion back to practical use cases and minimal needs. Example: Here's a setTimeout wrapper with cancellation, using a regular promise

Re: Promises, async functions, and requestAnimationFrame, together.

This is definitely interesting stuff. Have you considered rewriting this so that it only uses generators? If you did then you could test natively in Chrome and see if you get the same results. - Matthew Robb On Sat, Apr 23, 2016 at 7:01 PM, /#!/JoePea wrote: > Just to show a

Re: Promises, async functions, and requestAnimationFrame

is already handling that (like libraries do) and won't defer it any further but that's just a guess. The only spec I'm aware of that does not defer in this case is the es-observable spec. There has also been talk about being able to set the scheduler for promises which is something I wanted to bring up

Re: Promises, async functions, and requestAnimationFrame, together.

Just to show a little more detail, here's a screenshot that shows that the logic of the while-loop version of my animation loop fires inside each animation frame. I've zoomed out and we can see there's nothing fired between the frames:

Re: Promises, async functions, and requestAnimationFrame, together.

Alright, I did an experiment, and I'm really surprised at the results! Apparently, the logic (what would be drawSomething() in my previous example) is fired within the frame!! So, let me show you my original method for starting an animation loop. I'm working on a 3D project at http://infamous.io.

Re: Promises, async functions, and requestAnimationFrame, together.

On 4/23/16 4:09 AM, Salvador de la Puente González wrote: AFAIK, that should execute `drawSomething()` once per frame. Given a frame is each time the animatinFrame() promise resolves. What's not obvious to me is whether it will execute it before the actual paint for the frame (i.e. before or

Re: Promises, async functions, and requestAnimationFrame, together.

AFAIK, that should execute `drawSomething()` once per frame. Given a frame is each time the animatinFrame() promise resolves. On Sat, Apr 23, 2016 at 1:38 AM, /#!/JoePea wrote: > Is it possible? > > I thought maybe something like this: > > ```js > function animationFrame() { >

Promises, async functions, and requestAnimationFrame, together.

Is it possible? I thought maybe something like this: ```js function animationFrame() { let resolve = null const promise = new Promise(r => resolve = r) window.requestAnimationFrame(resolve) return promise } async function game() { // the game loop while (true) {

Re: non-self referencial cyclical promises?

raise an error about a cyclical reference here. Native promises should have no issue fixing this without any weak maps too. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

non-self referencial cyclical promises?

@Benjamin: Your example is different than Bradley's. Should be: ``` var r1, p1 = new Promise(r => r1 = r); var r2, p2 = new Promise(r => r2 = r); ``` ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: non-self referencial cyclical promises?

Sorry, the example fiddle was before the inclusion of bluebird - I got confused by the UI. Here: https://jsfiddle.net/cm9kvLqv/ It appears like native chrome promises also detect it (although with a less informative error and only for one of the promises) On Thu, Feb 25, 2016 at 10:17 AM

Re: non-self referencial cyclical promises?

For what it's worth, bluebird promises detect the error and reject with: ``` TypeError: Chaining cycle detected for promise # ``` So it's both possible and not a performance issue. For this case, a WeakMap is not needed for this case. https://jsfiddle.net/41ez2b6d/ . > We ran into c

non-self referencial cyclical promises?

When I first read that part of the spec, my understanding was that the two promises would cancel each other out by waiting for each other, but without performing an infinite set of PromiseJobs. The resolving functions created in step 1 of 25.4.2.2 that are set as reactions for the other promise

Re: non-self referencial cyclical promises?

s to start checking status >>> ``` >>> >>> According to >>> https://tc39.github.io/ecma262/#sec-promise-resolve-functions >>> it looks like this should cause a recursive and infinite set of >>> `EnqueueJob("PromiseJobs",...)` >

Re: non-self referencial cyclical promises?

>> https://tc39.github.io/ecma262/#sec-promise-resolve-functions >> it looks like this should cause a recursive and infinite set of >> `EnqueueJob("PromiseJobs",...)` >> > > I fear that's what the standard says, yes. The ES6 spec does too many (and > in some case

Re: non-self referencial cyclical promises?

e ES6 spec does too many (and in some cases, unreasonably many) `then` calls on promises anyway to be followed by an efficient promise implementation. [Promises/A+](https://promisesaplus.com/) in contrast says | Implementations are encouraged, but not required, to detect such | recursion

Re: non-self referencial cyclical promises?

With Mark’s direction, the v2 branch of Q handles "vicious cycles" through the WeakMap that maps promises to their underlying handler. Whenever a promise is resolved with another promise, it walks forward through the chain of promises that the promise handler "became" through r

non-self referencial cyclical promises?

I was doing some recursive data structure work and ended up with a cyclical promise that did not use a direct self reference. It can be reduced down to: ```javascript var af, a = new Promise(f=>af=f); var bf, b = new Promise(f=>bf=f); af(b);bf(a); // the problem a.then(_=>_) // some env/libs

Re: Promises as Cancelation Tokens

*F# cancellation* - on second thought implicit cancellation through cancellation like in F# is impractical because of the eagerness of promises. I don't think it's a valid alternative here. I've discussed this with Reed Copsey (an F# expert) and he explained the philosophy behind it to me

Re: Promises as Cancelation Tokens

> > For async functions, it would mean that any await expression could > potentially throw a CancelError Cancellation does not necessarily need to use `throw`, `return` is often more apt. I find. I would also recommend splitting the idea of cancellation into: abort semantics, and ignorance

Re: Promises as Cancelation Tokens

Implicit cancellation doesn't make sense if it involves a throw. Furthermore, implicit cancellation would never happen for your example - the 'await' clearly depends on the result of the operation, so it is in use and it would not make sense for it to be implicitly cancelled. For the record, every

Re: Promises as Cancelation Tokens

> > I think F#'s cancellation approach is also worth mentioning in the > discussion of alternatives as it has implicit but token-based automatically > propagating cancellation. > If you have any good links to reference materials on F#'s cancellation architecture, feel free to include them for

Re: Promises as Cancelation Tokens

> Another cancellation scenario is when the consumer of an asynchronous task no longer > needs the result of an operation. In this case, they will only have access to the Promise > unless the cancellation token is routed to them through some other path. For what it's worth - this is exactly how

Re: Promises as Cancelation Tokens

' property to propagate through all of the promises. This is somewhat equivalent to how you want a garbage collector to collect a whole tree of objects once they are no longer reachable. In JS (and in my opinion, basically all language environments) you want this to be explicit even if the GC is able

Re: Promises as Cancelation Tokens

Thanks for posting this. Great stuff! > On a page that loads 100 images four at a time, you would want 4 cleanup > actions registered, not 100. > And in order to keep it to 4 you need a way to unregister the action when you complete the operation, which the promise API doesn't give you. I

Re: Promises as Cancelation Tokens

f to handle such errors. Since we already have a well-defined and well-understood way to propagate errors using promises, I would prefer to have the async registration capability modeled as a promise, if possible. There is that "unregister" issue, though... ___

Re: Promises as Cancelation Tokens

cel) ``` Wouldn't this be better than using a Promise if we are relying on a synchronous check anyways? On Mon, Jan 4, 2016 at 12:30 PM, Kevin Smith <zenpars...@gmail.com> wrote: >> We have pretty sound cancellation semantics in bluebird 3. > > > Cool, I'm aware that cancellable pro

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-discus

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

om> wrote: > >> On Mon, Jan 4, 2016 at 9:01 AM, Domenic Denicola <d...@domenic.me> 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 discussio

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 promi

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 > cancellatio

RE: Promises as Cancelation Tokens

asynchronous. In .NET, cancellation notifications are executed synchronously, however this conflicts with the intent to ensure an asynchronous API is consistently asynchronous. This approach also allows cancellation tokens to be more general-purpose. By not directly tying cancellation into Promis

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 sys

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 cancela

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 <d...@domenic.me> 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 > https://github.com/promi

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) => {

  1   2   3   4   >