RE: Resolving Futures w/multiple values

From: Dave Longley [dlongley@digitalbazaar.com]

> I understand the desire to make something analogous to synchronous programming. However, sometimes analogies can be taken too far; it may be a mistake to hold so rigidly to an analogy that we miss out on useful functionality that improves upon the model we are analogizing.

> We don't have the same single return-value restrictions in modern asynchronous programming -- and developers have been taking advantage of that to write more expressive APIs. That this new ability has been embraced is both an indicator that maybe it should continue -- and a reason for Futures to support it.

I disagree that this is more expressive; in fact, not knowing how many success results you're going to get decreases general expressiveness, by making it hard to write generic functions that can be passed to different APIs. As an example of one of the many possibilities that would be lost by multiple fulfillment values/rejection reasons, I point you to the ever-excellent http://taskjs.org/.

If you want unstructured, unrestricted callbacks, you should use those. If you're looking for the benefits of promises, you should use those. Trying to find a hybrid model, by grafting the unstructured nature of callbacks onto promises, is misguided.

Since you made the calculator UIs analogy, I think I can afford to make a slightly more relevant analogy and say that while you're grafting unstructured features of callbacks onto promises, you might as well include the ability to both fulfill and reject at the same time. After all, this would allow you to capture Node.js APIs that send both an error and a result, e.g. when HTTP requests fail and send both an error and the response body.

Received on Tuesday, 23 April 2013 19:19:40 UTC