---------- Forwarded message ---------- From: Brendan Eich <bren...@mozilla.com> To: Kevin Smith <zenpars...@gmail.com> Cc: "Mark S. Miller" <erig...@google.com>, EcmaScript < es-discuss@mozilla.org> Date: Fri, 07 Feb 2014 16:05:20 -0500 Subject: Re: Promise.cast and Promise.resolve
>> A *working* implementation should be created and solutions to real-world use cases should be programmed using the design before any spec language is authored. Spec-language is apoor medium for communicating both design intent and programming intent. > Yes, this. I just want to add my two cents on this part here. A lot of us are following this thread from the outside, being unable to keep track of all the meetings ambiguities and agreements and the such. Tracking it is hard with all the ambiguities and 'big words' people sometimes throw and unclear use cases. The way 'we' see it is: - Promises solve an interesting problem - There are a number of promise libraries that are *working* implementations that solve real world use cases. They have evolved for several years _for_ those use cases. - I believe that was a big consideration for adding them to the specification to begin with. - Promise libraries _could_ have added some of the methods and alternatives discussed here but didn't. - Q is not the only library nor it is the 'de facto standard'. Kris is very knowledgeable but was not the only one building APIs. There are at least 4 more libraries that do promises (RSVP, When, Bluebird, kew, vow...). .chain , while very interesting is not very common to say the least. - Tens of thousands (probably more) of people have been using these libraries for years now. I mean no disrespect to the hard work of the people here. I know everyone who is participating in the discussion here is putting a lot of time and effort to better the language and the community. However, from my "complete" outside it sounds like: - There is a working tested solution that evolved through usage and solving real problems over several years*. * - The committee is dictating a lot of changes for it. - Changes are based on new design goals and theoretical considerations like "purity". I'm not saying there are no very good arguments for non-recursive assimilation and .chain (there are) , but they're still being "dictated" over existing library solutions. I was under the impression the goal is to adopt what works in practice as much as possible and not dictate solutions from the sky. If someone wants `a different API there is nothing preventing them from creating a library and doing that - then coming back with "Hey, our solution works, we have 1000 dependencies on NPM" or "on second thought, that sounded very interesting but people are complaining about usage". Sorry for the 'rant', will keep following closely. Thanks, Benjamin
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
