On Sat, Feb 8, 2014 at 2:57 PM, Quildreen Motta <[email protected]> wrote:
> > > Well, "promises" are a fairly old concept, with several different > implementations throughout the history of CompSci, and even in JavaScript > land itself. `.chain` itself is not common because it doesn't need to have > that name, but it is a common operation (`.then` encodes that operation, > for example, but you can't control when it gets applied). As for working > implementations of `.chain-able` promises, you can see: > https://github.com/folktale/data.future#example, and > https://github.com/fantasyland/fantasy-promises, although they are not > Promises/A+, it should be easy enough to implement `.cast` and `.then` on > top of those primitives. > > Phew! After that first sentence I thought I was getting a link to Liskov's paper(s) :) Both those libraries seem to have a low number of users, very few mentions and almost zero users in npm. I was not implying that it's "impossible" to implement chain, or monadic promises - I was implying very few people use them in JavaScript. Where, on the contrary people use the current model extensively in APIs. The debate from what I can tell is about standardizing something that exists but is not used nearly as much over something that exists and used extensively. > There are three things you want to do with a promise: > > - You want to sequence asynchronous computations, such that you can > specify computations that depend on a particular value. This is what > `.chain` does. > - You want to transform the value of a computation, but the computation > itself is synchronous. This is what `.map` does, and `.chain` can > generalise `.map`. > - You want to assimilate the result of a different promise. This is what > `.cast` does. > > Unfortunately, Promises/A+ only provide you with a `.then` method, which > does all of those things for you, but you can never control which of those > gets applied. Thus, `.chain` is a more general approach, and `.then` can be > easily derived from `.chain`. A specification should favour the general use > cases to make it easy for people to write more specific computations in > userland, instead of constraining the expressive power to particular > higher-level use cases. This is what the discussion on Promises right now > is about. > I'm not saying that `.chain` is a better or worse proposal here (or what I think at all). I'm talking about programmers in practice - those people in userland that are performing computations you speak of? They had a choice and they chose `.then`. Promise libraries such as Q (but not only) have been evolving for several years now. The way `.then` works was subject to change many times before but people in practice have found '.then' to be a simple and working solution. (For the record, when I think of .map I don't think of a synchronous computation - in fact I don't see that the fact the computation is synchronous in a promise chain is irrelevant - but again, this is not about _my_ opinion) > 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
