On Sun, May 26, 2013 at 7:30 AM, Russell Leggett <[email protected]> wrote: > 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.
The fact that we can make it monadic is just a bonus; any time you see "monad" just think "container++" - it's just a proven useful bit of structure on top which makes it easy to work with the values inside the container. (It's a bit more abstract than that, of course, but thinking in terms of containers works for many monads, and helps guide understanding toward the more abstract notion.) The use-cases for "generic container" promises have been explored. Many types of promises are fairly interchangable, because all they're doing is providing a tiny async barrier between you and the result, and so collapsing them together isn't very objectionable. Some types of promises, though, represent something significant and different - significant delays, significant computation, etc. (A big class of these "significant and different" promises will be lazy promises, which don't do their computation at all until someone registers a callback for the first time.) You don't want to automatically resolve them just because they were handed to you wrapped in another promise, or at least, you don't always want this; sometimes, you'll want to instead work with it *as a promise*, so you're not incurring extra delay until you actually need their inner value. > 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. I don't think single-unwrapping is so painful as to require a painful name to go along with it. Plus, given that we can make it monadic, the value comes from using a name generic enough to be useful for other monadic structures, so as we add more, the network effects accrue automatically (rather than requiring a library that just adds a bunch of aliases to various classes). ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
