- From: Benjamin Gruenbaum <notifications@github.com>
- Date: Thu, 28 Jan 2016 13:10:22 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/27/176417852@github.com>
> My concern with the more benign ignore semantics you mention is that it I see little technical difference - the lack of a way to consume one of these promises without implicit interest is still a problem Consuming a promise is very explicit interest in its result. > I see merely a recasting of expectations, with little guidance for folks looking for the cancellation hammer. The thing is - when we looked at actual real use cases no one is really looking for a "cancellation hammer". All the use cases we looked at (for example XHRs) work beautifully with disinterest cancellation semantics. That is - I looked at hundreds of projects w.r.t cancellation and answered over half a thousand promise question on Stack Overflow and have never seen someone who needed a "cancellation hammer" or even wanted one. Abort semantics are very frowned upon in other languages and systems too. Even in other primitives (like observables) it is _highly_ discouraged to have unsubscribe with multiple subscribers without refcounting. > You make a distinction between single and multiple subscriber promise-use as if they're two ways of working that users can choose between. Users don't need to care, cancellation would "just work". > they cannot guarantee that the net promise-chain is free of multiple subscribers (now or in future version of libraries) Of course, probably the vast majority of libraries returning promises wouldn't even support cancellation - the nice thing with this model is that with disinterest semantics that can be incrementally added later on, so people can start writing cancellation-aware code today and it'll be optimized later on. And of course, that's a _different_ model from abort semantics - which can be added anyway through a token-based approached (discussion on https://esdiscuss.org/topic/promises-as-cancelation-tokens ) --- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/27#issuecomment-176417852
Received on Thursday, 28 January 2016 21:10:57 UTC