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? 
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.


More information about the es-discuss mailing list