- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Wed, 24 Apr 2013 11:54:12 -0400
- To: Domenic Denicola <domenic@domenicdenicola.com>
- CC: "www-dom@w3.org" <www-dom@w3.org>
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