Le 26/04/2013 03:39, Tab Atkins Jr. a écrit :
On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble <[email protected]> wrote:
So what's an example
that motivates you to want to build a tower of promise types? The main one
I know of is the implementation (not use of) higher-order collection
constructs that use promises internally (e.g., the implementation of map and
reduce for an async, batching, flow-controlled stream of Promise<T>). That
kind of rare example can have more advanced hooks (like Q).
I think it's more important to see examples of why you want to
*flatten* them automatically. Having "towers of promises" keeps us
consistent with Futures-as-monads, which is useful from a theoreticaly
standpoint.
The Priority of Constituencies [1] asks us to be remain careful about
theoretical standpoints. How does the theoretical part translates into
helping users? authors (more than what I described at [2] which is
derived from my own experience)? implementors? specifiers?
I'm not saying the theoretical benefits don't exist, but I'd like to see
how they translate in concretely improving my life as a developer using
promises. I've explained the benefits I see for flattening from the dev
point of view, I'd like to see the equivalent.
This is similar, from an algebraic standpoint, to
allowing arrays of arrays, or sets of sets, or any other monadic
context doubled up.
Arrays of arrays make sense as a data structure. Promise of promise does
*in theory*, but as Kevin Smith said, in practice, promises are
featureless values; the only thing you care about is that an operation
is async and the actual non-promise eventual value that you'll get.
Given this practical use of promises, why bother with Future<Future<T>>?
I don't mind if they exist, but as a developer, I'd like
Future<Future<T>> to be hidden so that I don't have to deal with them. I
want all APIs I interact with to make me interact with promises and
non-promises values and that's it. I don't care about the rest. Hide
Future<Future<T>> under the carpet, please.
If super-experts want to play with Future<Future<T>>, give them, but
don't make that the default way to interact with promises. (as a side
note, Mark Miller and Domenic Denicola are some of the most experts I
know and they're also asking for flattening. It sounds strong enough of
a signal for me to give on non-flattening; if they had any use, they
would have expressed it).
David
[1] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
[2] https://mail.mozilla.org/pipermail/es-discuss/2013-April/030192.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
