Let's separate two forms of complexity: a) Complexity visible to those who must use, implement, or understand the full API including .flatMap.
b) Complexity visible to those who only use, implement, or understand the subset without .flatMap. The main beauty of AP2 is that it minimizes the complexity of #b. My hypothesis and hope is that #b has the same complexity as a Promises/A+ compatible promise proposal would be without flatMap. If adding flatMap support increases the complexity of #b, that would be bad. Do you see any way in which it does? Note that #b differs from "a Promises/A+ compatible promise proposal would be without flatMap" in one substantive way: Moving the recursive unwrapping/flattening/assimilation to the input side of .then. As already discussed on the Promises/A+ list, this should be close to compatible with Promises/A+ code, as the difference is only visible when the behavior of recursive unwrapping is side-effect-dependent. Also, it should make things * simpler*, as the "resolve" operation (or whatever it would be called) would no longer need to do the recursive unwrapping. By putting recursive unwrapping on the input side of .then, it need not appear anywhere else. Assuming TC39 declares consensus on AP2, I expect Promises/A+ to move the recursive unwrapping to the .then input, or to at least allow it, so that TC39 and DOM promises remain compatible with Promises/A+. Likewise with Q. I don't expect either Promises/A+ or Q to ever provide .flatMap. I leave it to the DOM folks to evaluate whether the subset they need soon needs to include .flatMap. On Mon, Aug 19, 2013 at 5:11 PM, Kevin Smith <[email protected]> wrote: > > With all the changes to Promise (addition of Promise#flatMap, recursive >> unwrap on input side of Promise#then, etc.), it does seem that fulfill's >> use case has become a bit muddled. I'll admit to still being partial to the >> earlier design (fulfill/resolve/reject, adopt without recursive >> unwrap/flattening) as it was a much simpler and more straightforward API. >> > > I tend to agree. > > { Kevin } > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
