I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:
1 "library author doesn't want nested Promises."
2 crossing Promise library boundaries can create unwanted nesting
There is little to be said about 1, only that those library authors still
have a choice: add a separate recursive flattening operation and keep
the thenable operations unharmed, or give up on Promises being
thenables in the monad-inspired JS patterns sense (and hence give
up on profiting from generic thenable library code).
The second point is somewhat more interesting, as it stems from yet
another convenience-driven thenable deviation: if a then-callback does
not return a Promise, its result is implicitly lifted into a Promise; the
unwanted nesting apparently comes from different libs not recognizing
each others promises, mistaking foreign promises for values, and lifting
them into their own promises. Recursive flattening (assimilation) is
then intended as a countermeasure to recursive lifting of foreign
promises.
It will come as no surprise that I think implicit lifting is just as mistaken
and recursive flattening;-) Both should be moved to explicit convenience
methods, leaving the generic 'then'/'of' interface with the properties
needed for generic thenable library code.
Claus
I think we see a correlation -- not a 1.0 correlation, but something. Those
who've actually used promise libraries with this flattening property find
it pleasant. Those who come from either a statically typed or monadic
perspective, or have had no experience with flattening promises, generally
think they shouldn't flatten.
I think the dispute could be settled easily:
- flattening 'then' is a convenience
- non-flattening 'then' is necessary for promises being thenables
(in the monad-inspired JS patterns sense)
Why not have both? Non-flattening 'then' for generic thenable
coding, and a convenience method 'then_' for 'then'+flattening.
That way, coders can document whether they expect convenience
or standard thenable behavior. And we can have convenience for
Promise coding without ruining Promises for more general thenable
coding patterns.
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
