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.
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
