Re: Promise/Future: asynchrony in 'then'
Juan already pointed out the queue a task language, so this is answered. This is far too glib. The spec may very well be wrong on this point. The design goal isn't to require a full yeild of the event loop, but instead to force async code flow -- that means that resolving and calling back should be able to happen at end of microtask; the same timing as Object.observe() callbacks. Promises/A says has an open issue on whether callback handlers should be put on the event queue or executed immediately. Promises/A+ Promises/B both specify that callbacks may not be invoked in the same turn of the event loop. According to the harmony:observe doc, it was suggested that Schedule change events to be delivered asynchronously “at the end of the turn”. These may all be wrong, but all seem to be hitting at the fact that in a new turn is the *easiest* way to force asynchronicity. Maybe we need to specify that all callbacks must be invoked asynchronously, regardless of which turn in the event loop they occur. -s ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
Lucas Smith wrote: IMO, cancelation is not appropriate for promises/futures. (sticking with the name promises, sorry for the distraction). Agreed. Perhaps I'm missing something, but is cancel() conceptually different from passing a Future's corresponding Resolver around so that the program can invoke reject() at will? This seems like it's a new, irretrievably broken way to do something you already can do. -sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
I don't know what the right shape for a cancellation API is, but one should not assume that this problem is inherent to cancellation. I don't think it is. Take my input with a grain of salt, but I think it is. Futures form a cascading pipeline (a series of tubes, if you will) that it promises to follow, either succeeding or failing but always continuing. Cancellation doesn't fit that model, because it involves either destructively reshaping the pipeline after it's started or trying to shove events in the wrong direction. If a value is no longer needed and you know ahead of time that it may not be, then a) keep the resolver and reject (reject() takes a value. Use it.), or b) put an `if` in the success callback. -sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
