Re: Resolving Futures w/multiple values

On 04/23/2013 03:19 PM, Domenic Denicola wrote:
> 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.

I think it would be unwise of us to assume that developers aren't going 
to want to reuse existing code that isn't based on a Promises/Futures 
API. So I would expect there to be hybrid code, unless the 
Promises/Futures API is too restrictive to allow for this to happen. 
Maybe it isn't already and this issue is rare enough (I don't know) that 
it won't come up. But it would be nice to provide developers with the 
option of continuing to use their libraries in ways that seem natural to 
them -- especially if they won't understand why it is done differently.

As for http://taskjs.org and the new ES6 usage of 'yield' with values 
that define 'then' -- I don't think this behavior has to change or be 
disabled in any way. From my understanding, the behavior of 'yield' 
under that circumstance is to pass two functions to the 'then' property 
of the value passed to 'yield'. If the first function is called, then 
the first parameter (regardless of the number of parameters) is what is 
returned (yielded). This would not change even if the 'resolve' function 
in the Futures API were able to take more than one parameter. Developers 
wouldn't have the option of accessing those parameters using a 'yield' 
pattern, but they would otherwise. They could still box the values if 
they wanted to use them with 'yield' -- but at least the reason for 
doing it there would be more evident: you can only yield a single value 
because that's a restriction of the language. Conversely, passing only 
one parameter to a function is not a restriction and I'd expect the 
reasoning for that restriction to be somewhat obtuse to many developers.

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

I wouldn't object to supporting multiple parameters in the error handler 
either. I don't think these things cause a problem for the common case 
and they are useful under the right circumstances.

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Wednesday, 24 April 2013 15:53:18 UTC