On 29/01/2014 5.12, Kris Kowal wrote: > In this case, a half pursuit of type purity is a side quest at the > expense of users. Having two ways to resolve and two ways to observe a > promise is unnecessarily confusing. In my experience, one method like > "then", that unwraps recursively, and one function, like "Promise.cast", > that automatically lifts if necessary, and "then" handlers that return > into the waiting hands of "Promise.cast" are coherent and ergonomic. > Having a choice between "cast" and "resolve" and a choice between "then" > and "chain", will leave developers unnecessarily confused and worried > all the while they use or abandon Promises as too subtle.
As an imperative programmer, I confirm I'm left worried and confused ;-) But I understand that functional programming might need more complexity. I would be less confused if functionality that is only relevant for functional programming would be separate and inaccessible by default, even if supported and optimized at the implementation level. For example: ```js let p1 = FunctionalPromise.accept(...) FunctionalPromise.chain(p1, ...) ``` And no "Promise.accept" or "p1.chain" methods to be chosen over "Promise.cast" and "p1.then". Paolo _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
