Re: Cancellation architectural observations

2015-03-01 Thread Salvador de la Puente González
I think this did not reach the mailing list to the W3: https://esdiscuss.org/topic/cancelable-promises#content-9 Actually the result cancellation is different from promise cancellation. First is full of implementation details, thus you are talking about smart cancellation. It is not smart, is the

Cancellation architectural observations

2015-03-01 Thread Dean Tribble
Another thread here brought up the challenge of supporting cancellation in an async environment. I spent some time on that particular challenge a few years ago, and it turned out to be bigger and more interesting than it appeared on the surface. In the another thread, Ron Buckton pointed at the .Ne

Re: Cancelable promises

2015-03-01 Thread Kevin Smith
> > > > So again the question is: can we come up with a cancellation-token-style > pattern which is JS-ergonomic? > > I tried to discuss some stuff in that direction at > https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75342617 > > I think using a promise in place of a "token i

RE: Cancelable promises

2015-03-01 Thread Domenic Denicola
From: Kevin Smith [mailto:zenpars...@gmail.com] > So again the question is: can we come up with a cancellation-token-style > pattern which is JS-ergonomic? I tried to discuss some stuff in that direction at https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75342617

Re: Cancelable promises

2015-03-01 Thread Kevin Smith
> > > That design seems far cleaner than adding functionality directly to > promises, but can it be made JS-ergonomic? > > The question we need to consider when it comes to a general design for canceling async tasks is this: how does one offer cancellation when defining an async task using an asyn

Re: iterator next method returning new object

2015-03-01 Thread Benjamin (Inglor) Gruenbaum
Well, if the user caches the result (in order to pass it to another iterator) they'll get unexpected results. Iterator A yields: ```js {value: 1, done: false} {value: 2, done: false} {value: 3, done: false} {value: 4, done: false} ``` There are two consumers for the iterator (sending the result

Re: Function "name" property

2015-03-01 Thread Leon Arnott
On Sun, Mar 1, 2015 at 3:28 AM, Allen Wirfs-Brock wrote: > > If you want both a TCP-able from and a local (most closely enclosing > callable thing) form then the later should also presumably also be > applicable at the top level of functions. > > The 'in' meta property prefix in combination with