CompletableFuture

[David M. Lloyd]

On 11/28/2012 11:03 AM, Doug Lea wrote:
> On 11/28/12 11:09, Remi Forax wrote:
>
>>> The void completion methods don't return new CompletableFuture (no need)
>>> but just "return this" to be nice to fluency fans.
>>
>> aaaaaah,
>> It means that with
>>    CompletableFuture<T> c = completableFuture.then(e -> foo(e));
>> c.isDone() can be true even if foo() has still not finished.
>>
>> Having a fluent interface is a nice trick but here, the resulting
>> semantics is
>> too weird IMO.
>>
>
> Thanks. Good point. I initially defined these as void (as opposed to
> the Function ones, that return a new one to maintain value). Changing
> to "return this" makes them much simpler to use but as you point
> out makes it look like the "." in a compound expression refers
> to the wrong thing. I guess the best way out is to
> actually create/return a little CompletableFuture<Void> here,
> which doesn't appreciably inflate cost and precludes misinterpretation.
> So...
>
>     /**
>       * Creates and returns a CompletableFuture> that is completed
>       * after performing the given action with the result of this
>       * CompletableFuture if/when it completes normally.
>       *
>       * @return the new CompletableFuture
>       */
>      public CompletableFuture<Void> then(Block<? super T> action);
>
>
> And similarly for and(), or(), exceptionally().
> We still have the function vs action method overriding issue though.

Maybe this is getting a bit to abstract, but anecdotally speaking we 
have found that "do A then B" is "less good" than "do B when A is done", 
i.e. model the problem in terms of tasks and their dependencies rather 
than as a sequential chain of tasks to run in order.  It's just 
inherently cleaner and potentially more performant (any given task can 
execute as soon as its dependencies are satisfied; there are no 
artificial sequences imposed on tasks).  But, at the same time, that 
mode of thinking seems to be fairly incompatible with Future.

-- 
- DML