A Challenge Problem for Promise Designers (was: Re: Futures)
claus.reinke at talk21.com
Thu Apr 25 15:21:28 PDT 2013
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
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.
>> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss