News for hackers. Stuff that matters.
Re:Cancelable Promises: Why was this proposal withdrawn? by jrochkind1 on Monday December 19, 2016 @12:33PM (#13213141)
> So cancelable promises reignite all the old debates plus there's no obvious right way to do it, like should it be a 3rd state which could cause compatibility issues…

It seems obvious to me that the 'right' way to do it is a cancelled promise is in the error state, with the error object just being a new type of error CancelledPromise or something.

But I guess once you start getting into it, this becomes less obvious?

Re:Cancelable Promises: Why was this proposal withdrawn? by ralfn on Tuesday December 20, 2016 @06:24AM (#13218945)
No, the right way is to fix the fetch() api to not return a promise and reflect on why the system was so broken that fetch() api was released with such an obvious flaw.

Because Promises don't need to be cancellable. This has nothing to do with promises. Fetch requests need to be cancellable. But they, in all their wisdom, decided that the fetch API returns a promise. So now promises need to become whatever the hell the fetch API actually needs to return.

You would almost think design by committee is fundamentally flawed, and design by community even more flawed.

Because the edge cases are never obvious. For every new feature the question shouldn't be "do i make 99 programmers 1% happier?", but do i make 1 programmer cry upto the point where they would stab my eyes out if they could?

We've all been that 1 programmer, and yes, i would if i could. It's a clusterfuck of bike shedding. Most new ES2016 have details that haven't been though through and will end up being hated on the same level as '==' and 'NaN'.

The dev-leads of the different javascript engines should not just be able to veto. They should be able to veto people out of the room, out of the debate. And we should celebrate it every time they take advantage of that power. Or just give up on Javscript all together and just let the rot fester.

Re:Cancelable Promises: Why was this proposal withdrawn? by jrochkind1 on Tuesday December 20, 2016 @09:06AM (#13219855)
I think fetch definitely needs to (at least as an option) offer some kind of async API built-in without adding another dependency. Async is likely the most common use case in the browser. I have not been displeased with the fetch->promise API, it works well for me, and is definitely a lot more convenient than XMLHttpRequest. Which part do you disagree with from your experience?
Re:Cancelable Promises: Why was this proposal withdrawn? by ralfn on Tuesday December 20, 2016 @10:32AM (#13220646)
I love the fetch-api as well, but it doesn't allow for one to cancel the request. Which is why people want to change Promises in the first place. Because the committee in all its wisdom has specified that the fetch-api returns a promise. So the only way to make the requests of the fetch-api cancellable is to change the return type of the fetch-api. But that has been standardized to be a Promise. So now they want to change Promises to be whatever the hell they need from the fetch-api.

Do i need to cancel requests? Not really. But not being able to cancel requests is now driving a shitstorm of short-sighted proposals to mutate the Promise contract into some sort of 'whatever the hell the fetch-api really needs reply object'.

Re:Cancelable Promises: Why was this proposal withdrawn? by jrochkind1 on Tuesday December 20, 2016 @10:59AM (#13220943)
There's probably a (hypothetical API) way to get a _fetch_ to be cancellable, even though it returns a promise, without altering the API of general promise. Some way to get a reference to the request going on and cancel it, which would result in the promise failing (assuming it hadn't completed yet) with a FetchCancelledError or something. One could certainly imagine building such an API if one were polyfilling fetch onself built on XMLHTTPRequest (which can be cancelled).

I won't bother trying to think it through though cause it's clearly pointless except as an intellectual exersize!

I actually like that fetch returns a Promise, I find it convenient, I don't think it was a bad choice at all. To make Promise part of ES6 as a general-purpose async primitive, and to make Fetch return one. I also see how it would be nice to allow fetches to be cancelled -- although I'm not sure I've ever needed/wanted to do that, I could see how I might in the future.

It is boggling that a bunch of smart interested people haven't been able to figure out _some_ solution to this.

Re:Cancelable Promises: Why was this proposal withdrawn? by cwmma on Tuesday December 20, 2016 @08:20AM (#13219515)
> The dev-leads of the different javascript engines should not just be able to veto. They should be able to veto people out of the room, out of the debate. And we should celebrate it every time they take advantage of that power. Or just give up on Javscript all together and just let the rot fester.

this would ironically tend to be applied to people like you

Re:Cancelable Promises: Why was this proposal withdrawn? by ralfn on Tuesday December 20, 2016 @10:24AM (#13220552)
No irony :) I don't think i should be in that room. I know enough to know how little i know. I also know enough to recognize a naive short sighted proposal such as 'cancellable promises'.

That doesn't mean it should be me dismissing that feature. But i am very much smiling that the people that should be in that room, did dismiss it.

Re:Cancelable Promises: Why was this proposal withdrawn? by cwmma on Monday December 19, 2016 @01:17PM (#13213553)
Bingo, it turns the same thing wasn't wasn't obvious to everyone
Re:Cancelable Promises: Why was this proposal withdrawn? by jrochkind1 on Monday December 19, 2016 @09:02PM (#13216777)
weird. it would be interesting to read more of the debate/discussion, is it actually avail anywhere?