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

Claus Reinke claus.reinke at talk21.com
Fri Apr 26 06:47:59 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
> 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).

Yes, I had seen that, but it doesn't explain where those nested Promises
are supposed to come from. For a normal thenable thread (without
implicit flattening or lifting), the nesting level should remain constant - 
.of(value) wraps value in a Promise, .then(cb) unwraps the intermediate 
result before passing it to cb, and cb constructs a new Promise.

In a later message, you suspect the reason for implicit flattening is
fear of buggy code that may or may not wrap results in Promises. You
say that such code may result from refactoring but, in JS, Promise<value> 
is different from value, so trying to hide the level of promise nesting is 
likely to hide a bug. Yes, it is more difficult to spot such bugs in JS, but 
they need to be fixed nevertheless. Wrapping them in more duct-tape 
isn't helping.
> 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.

My own argument is not for nested futures themselves, but (1) for 
futures to offer the same interface (.of, .then) as other thenables, which
(2) implies that there is to be no implicit lifting or flattening in .then.

In other words, you are worried about others giving you arbitrary
nested promises and want to protect against that by implicit flattening,
whereas I want to have control over the level of nesting and keep that
level to one. For promises, I don't expect to use nested promises much, 
but I do expect to define and use thenable methods that should work 
for promises, too.



More information about the es-discuss mailing list