Re: Resolving Futures w/multiple values

On 04/24/2013 11:01 AM, Bjoern Hoehrmann wrote:
> * Dave Longley wrote:
>> In order to convert this continuation-passing style API to a Future, a
>> wrapper creates a new function that wraps the async operation and passes
>> a callback that will call reject() if a non-null 'err' parameter is
>> defined and resolve() with an array containing both 'bar' and 'baz'
>> otherwise. The code to use such a wrapper and its resulting Future might
>> look like:
>>
>> futureFoo = wrap(foo);
>> futureFoo(param1, param2).done(function(value) {/*value is [bar,
>> baz]*/}, function(err) {})
>>
>> This will be a bit odd for anyone used to using the library, but it is
>> at least usable, unless 'bar' can be either an array or an object and
>> 'baz' is optional. Then the results are indeterminate.
> I don't see the problem here. `value` would never be `bar`, it would be
> `[bar, ...]` because you always box the value to avoid this problem.

It wouldn't be a problem if you *always* box the value. A possible 
solution to this problem would be to provide two API methods for 
transforming node.js-style async operations -- one that always boxes 
(for those operations with multiple parameters) and one that doesn't 
(for those operations with a single parameter, to avoid the annoyance of 
having to unbox).

However, I think that if the annoyance of dealing with boxing/unboxing 
could be avoided, that would be preferable. It seems like an unnecessary 
limitation and, my guess would be, a lot of developers who end up having 
to wrap continuation-passing style functions to unify under a 
Promises/Futures API would not understand the limitation and would also 
find it frustrating/ugly. Whether or not that will hurt adoption -- or 
if the community cares about that adoption is unclear. It would be nice 
if everything just continued to work "as is".

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Wednesday, 24 April 2013 15:11:44 UTC