github at esdiscuss.org (2013-07-12T02:27:21.589Z)
Just one more from the peanut gallery. I'm a big fan of the Q library. I use it in production code. I like the auto-unwrapping and feel like it works in a way that I expect. I like E and greatly respect Mark's work and opinion as well. I can't really think of any situations where I would need nested promises. Still, in this debate I find myself coming around to Tab's proposal, including his details about flattening on the read side. I strongly come down on the path of using thens and recursive unwrapping as the happy path that everyone should really use unless they know what they're doing. Still, the additional method does not come at a high cost in my opinion. If there is going to be a standard "hacky workaround", then the additional method seems pretty straightforward and elegant. On the other hand, if *nobody* is going to actually need the method, then I guess it may very well be dead weight. I'm sorry if I have just missed it trying to keep up to date, but what are the compelling use cases. I mostly understand the monad thing, I can recognize them when I see them - I've used haskell. Is the only reason so that a monadic style can be used, with promises included? Perhaps that's enough, but I guess I'd really like to hear something more direct. Also, I'd like to know how many people are really using monadic JavaScript in production or if its mostly just a hypothetical scenario. Finally, if we wish to add the method and we worry about the burden on developers who have no interest in monads, perhaps a method name that really comes from *their* perspective, or one that feels more *experts only* would seem less burdening. Something like "resolveOnce" or "forceInvokeNext" or "resolveNonGreedy" or even "monadicThen". Some of those are probably more acceptable than others, but I think that "chain" will too likely seem useful to people who won't want to use it. JavaScript developers, I think have expectations about what chain means. For most people, they with just think of wrapping something for method chaining.
On Sat, May 25, 2013 at 6:00 PM, Brendan Eich <brendan at mozilla.com> wrote: > Tab Atkins Jr. wrote: > >> AP2 from Mark's slides: >>> > >>> > AP2 (Based on Tab’s latest) >>> > • Q.fulfill // lifting >>> > • Q() // autolifting, resolve >>> > • p.then // deep flattening >>> > • p.flatMap // “chain” >>> >> >> Apologies for being a broken record, but just to make sure the detail >> isn't lost in the noise... >> >> AP2 is*almost* right. If .then() only flattens on the read side, >> it's perfect. >> > > With you all the way on this one. > > Who proposes flattening the return value ("write side", right)? Just one more from the peanut gallery. I'm a big fan of the Q library. I use it in production code. I like the auto-unwrapping and feel like it works in a way that I expect. I like E and greatly respect Mark's work and opinion as well. I can't really think of any situations where I would need nested promises. Still, in this debate I find myself coming around to Tab's proposal, including his details about flattening on the read side. I strongly come down on the path of using thens and recursive unwrapping as the happy path that everyone should really use unless they know what they're doing. Still, the additional method does not come at a high cost in my opinion. If there is going to be a standard "hacky workaround", then the additional method seems pretty straightforward and elegant. On the other hand, if *nobody* is going to actually need the method, then I guess it may very well be dead weight. I'm sorry if I have just missed it trying to keep up to date, but what are the compelling use cases. I mostly understand the monad thing, I can recognize them when I see them - I've used haskell. Is the only reason so that a monadic style can be used, with promises included? Perhaps that's enough, but I guess I'd really like to hear something more direct. Also, I'd like to know how many people are really using monadic JavaScript in production or if its mostly just a hypothetical scenario. Finally, if we wish to add the method and we worry about the burden on developers who have no interest in monads, perhaps a method name that really comes from *their* perspective, or one that feels more *experts only* would seem less burdening. Something like "resolveOnce" or "forceInvokeNext" or "resolveNonGreedy" or even "monadicThen". Some of those are probably more acceptable than others, but I think that "chain" will too likely seem useful to people who won't want to use it. JavaScript developers, I think have expectations about what chain means. For most people, they with just think of wrapping something for method chaining. - Russ > > > /be > > ______________________________**_________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130526/a1df49db/attachment.html>