Re: Resolving Futures w/multiple values

On 04/24/2013 12:15 PM, Brandon Wallace wrote:
> The problem I find with this suggestion is where do you draw the line? 
>  There are already good mechanisms to handle passing around tuples. 
>  Why make the Futures API also provide custom support for tuples?  And 
> if it does, why stop there?  Wouldn't it also be nice if the futures 
> could capture our context and set it when calling our callbacks?
>
> someFuture.done(callback, context); // callback will be called with 
> "context" as its 'this'.
>
> I mean, we have Function.bind, but wouldn't this be more convenient 
> since maybe some other old-style async API provided the convenience 
> and not also providing the same convenience might make it 
> frustrating/ugly?  I'm sure people could think up other things that 
> might be convenient, but they aren't necessary and their exclusion 
> does not reduce the functionality of the API in any meaningful way.

I don't buy this slippery slope argument. I think the change would be 
fairly minor.

>
> Instead of making every new API that comes out re-implement features 
> the language already supplies, why doesn't the hypothetical API that 
> wraps the node.js-style methods shield you from this concern and 
> provide a way to wrap the callbacks also?
>
> callback = function(bar, baz) { ... }; // old-style callback that I 
> now want to use with future API
> futureFoo = wrap(foo);
> futureFoo(param1, param2).done(wrapCallback(callback)); // 
> wrapCallback will unbox for me.
>
> This avoids a whole nest of problems related to chaining futures and 
> waiting for a collection of Futures where each future might resolve to 
> a different number of results.  It would be frustrating and mystifying 
> if you lost the extra results just because you chained your futures.

Weaving wrapped/non-wrapped promises together in a chain could get 
fairly ugly with this approach. But it would "work". I just think that 
it could be easily avoided with what I think is a minor change. Your 
mileage may vary. If the consensus is that this is not useful or 
necessary, I can accept that. I thought it important to bring up -- as 
we may see complaints related to this in the future.

>
> --
> Brandon
>
> ------------------------------------------------------------------------
> *From:* Dave Longley <dlongley@digitalbazaar.com>
> *To:* Bjoern Hoehrmann <derhoermi@gmx.net>
> *Cc:* www-dom@w3.org; Anne van Kestern <annevk@annevk.nl>; 
> slightlyoff@chromium.org
> *Sent:* Wednesday, April 24, 2013 10:12 AM
> *Subject:* 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.
>
>
>
>


-- 
Dave Longley
CTO
Digital Bazaar, Inc.