Domenic Denicola wrote:
The amount of heat Kevin has piled on to promises-unwrapping, repeatedly, has been puzzling and unwarranted, but I have chosen mostly to set it aside, as the words of someone who did not care to understand the whole history and design constraints involved in writing this spec.
Apologies for seeming to side with Kevin's "shenanigans", that's the wrong word. I shouldn't have cited it without noting how it usually implies bad intent. What I was reacting too, perhaps Kevin is as well, is the difficulty in getting something seemingly simple (as library code) standardized.
And you're right, there was a lot of hard work to get to where we are. Thanks for all you've done. I am in no position to complain, having stayed away from the long promises threads over the last many months, mostly.
But (and I fell for this too, no excuses) combining two conflicting APIs into one proposal was always a mistake.
Andreas R. argues we can live with the over-wrapping in resolve, and seems to argue that my higher priority points (1, committee "do both" error; 2, .all etc. use .then not .chain) are either not problems or minor enough to live with.
Ron Buckton just proposed a "do both" solution that is at least properly parameterized in the constructor, so combinators (2) work. But it's still a stinking optional state flag that forks runtime semantics and API reasoning chains (1), creating bug habitat and probably pleasing no one much.
My "realism" argument seems strong, and your summary backs it: DOM was only using .then and .resolve, that's all they needed. That's all library Promise users use, in general (please correct me if I'm wrong). That is what Promises "are" in a real sense that constrains our standards efforts for ES6 and the DOM.
HTH, and thanks again for all your work. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
