A Challenge Problem for Promise Designers (was: Re: Futures)

David Bruant bruant.d at gmail.com
Fri Apr 26 01:36:28 PDT 2013


Le 26/04/2013 00:21, Claus Reinke a écrit :
> 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
Perhaps you didn't read my post then? 
https://mail.mozilla.org/pipermail/es-discuss/2013-April/030192.html
I've shared experience on why flattening promises are convenient (easier 
refactoring, easier to reason about) and why non-flattening would be 
annoying (impose some sort of boilerplate somewhere to get to the actual 
value you're interested in).

Kevin Smith made a point that I believe is underestimated by 
non-flattening advocates:
> I think flattening is also tied inextricably to the fact that promises 
> are a featureless wrapper for values.  Nobody cares about 
> promises-as-values because of this featureless-ness.  And because they 
> are completely uninteresting as values, programmers can think 
> "straight through" to the eventual value.
>
> This is highly simplifying for the programmer, especially in the 
> context of complex asynchronous data flows.

 From experience, I couldn't care less for a wrapper for a wrapper for a 
value. I just want wrappers and values. Promises are just async boxes.

Beyond rationale, I'd like non-flattening advocates to show use cases 
where a Future<Future<T>> can be useful; more useful than just Future<T> 
and T.

David


More information about the es-discuss mailing list