On Sat, May 25, 2013 at 10:30 AM, Brendan Eich <[email protected]> wrote: > Sam Tobin-Hochstadt wrote: >> In the meeting, there were (a) people advocating for styles of >> programming along the lines that you (Tab) have put forward, like me, >> (b) people advocating for Q-style programming, like Mark, Yehuda, and >> Tom, and (c) genuine concern about the complexity budget of the >> promise API, expressed most by Luke Hoban, but felt by all of us. Were >> it not for this last concern, I think AP2 would have seemed more >> attractive. But since the set of methods available on Promises >> themselves is the most visible part of the API, and AP2 doubles its >> size, that told heavily against AP2. > > 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. The difference is undetectable to code that sticks strictly with .then(), but it allows for easier composition with .chain()-based code. For example, a .then() callback can just return a promise from some other function. This other function *could* be returning a nested promise (it might be a database which can hold promises, for example), and so a .chain() off of it can usefully just unwrap the DB promise and deal with the inner promise. If .then() flattens on the return side too, this possibility is lost - the unwrapping behavior infects the chained future regardless of how you interact with it. I'm ambivalent about whether .flatMap/chain() should be properly monadic (rejecting the chained promise with a TypeError if you return a non-promise from the callback) or have the same loose behavior as .then() where it allows you to return a non-promise and figures out what you mean. I lean toward the former because .then() exists already, but wouldn't die if the latter were chosen. ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
