On 8 February 2014 12:26, Benjamin (Inglor) Gruenbaum <inglor at gmail.com>wrote:

> On Sat, Feb 8, 2014 at 2:57 PM, Quildreen Motta <quildreen at gmail.com>wrote:
>
>
>> One of the problems with just following existing solutions is that you'd
>> also be copying the evolution mistakes and technical debts in those
>> solutions. The committee **is** considering the existing solutions, and the
>> use cases presented by people, which is a good thing. For example, for the
>> "asynchronous map" use case, `.then()` is not usable short of adding plenty
>> of special cases, and special cases don't compose cleanly. Standards are
>> difficult because what you decide will shape the solutions that people
>> write in the language for decades, standards evolve slowly, that's why you
>> have less chances to make mistakes — in a library you can make a mistake
>> and promptly fix it in the next version, this is not true of standards.
>>
>
> My problem with that paragraph is that promise libraries _have_ evolved
> for years. There are several libraries - Bluebird, Q, when, RSVP or any
> other promise library with _a lot_ of dependent libraries on NPM and more
> than a thousand stars on GH. They're all open source and At any point
> anyone could have:
>
>  - Add 'chain' with a PR, explain why it's better and convince _any one of
> those_ maintainers why it should be added. I've seen work in Promise
> libraries several times.
>  - Open an issue with convincing real life use cases and explain them -
> advocate .chain and get people to use it. I've seen this work in promise
> libraries several times and have done so myself.
>  - Fork any one of them (most, if not all have permissive MIT licenses)
> and replace .then with .chain (or add it). It's also no problem to interop
> with existing A* libraries.
>  - Build a new library and get users - I personally recently converted
> over 100 KLOC to use a promise library that didn't exist a year ago.
>
> I'd just like to add I did not make (at least intentionally) a single
> technical argument here. It's merely the process I'm concerned about.
> Choosing APIs that have no extensive use in the ecosystem over ones who do
> without first battle testing them concerns me.
>


It has been discussed at length before (
https://github.com/promises-aplus/promises-spec/issues/94), and continued
in es-discuss. Specially because there are use cases for the standard
library that are not covered by `.then` (Andreas has discussed them
before). And again `.then` is just a special case of `.chain`, so the
proposal that was being discussed was to give people `.chain` and `.then`,
where `.then` would be written in terms of `.chain`.


-- 
--
Quildreen "(Soreλ\a)" Motta  (http://robotlolita.github.io/)
*— JavaScript Alchemist / Minimalist Designer / PLT hobbyist —*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140208/f807d816/attachment.html>

On 8 February 2014 12:26, Benjamin (Inglor) Gruenbaum <inglor at gmail.com>wrote:

> My problem with that paragraph is that promise libraries _have_ evolved
> for years. There are several libraries - Bluebird, Q, when, RSVP or any
> other promise library with _a lot_ of dependent libraries on NPM and more
> than a thousand stars on GH. They're all open source and At any point
> anyone could have:
>
>  - Add 'chain' with a PR, explain why it's better and convince _any one of
> those_ maintainers why it should be added. I've seen work in Promise
> libraries several times.
>  - Open an issue with convincing real life use cases and explain them -
> advocate .chain and get people to use it. I've seen this work in promise
> libraries several times and have done so myself.
>  - Fork any one of them (most, if not all have permissive MIT licenses)
> and replace .then with .chain (or add it). It's also no problem to interop
> with existing A* libraries.
>  - Build a new library and get users - I personally recently converted
> over 100 KLOC to use a promise library that didn't exist a year ago.
>
> I'd just like to add I did not make (at least intentionally) a single
> technical argument here. It's merely the process I'm concerned about.
> Choosing APIs that have no extensive use in the ecosystem over ones who do
> without first battle testing them concerns me.
>


It has been discussed at length before (
https://github.com/promises-aplus/promises-spec/issues/94), and continued
in es-discuss. Specially because there are use cases for the standard
library that are not covered by `.then` (Andreas has discussed them
before). And again `.then` is just a special case of `.chain`, so the
proposal that was being discussed was to give people `.chain` and `.then`,
where `.then` would be written in terms of `.chain`.