CompletableFuture

[Doug Lea]

On 11/29/12 09:53, Remi Forax wrote:
>
> again Future<? extends U>.

Thanks.

>
> I think that CompletableFuture<?> is better as return type than CompletableFuture<Void>
> otherwise users may want to declare a local variable Void.

We end up using explicit Void params in FJ stuff a lot
and people seem OK with it, so we might as well make these
use the same conventions unless anyone can think of a reason
otherwise.

>>     /**
>>      * Creates and returns a CompletableFuture that is completed with
>>      * the result of the given function of either this or the other
>>      * given CompletableFuture's results if/when either complete
>>      * normally.
>>      *
>>      * @return the new CompletableFuture
>>      */
>>     public <U> CompletableFuture<U> or(CompletableFuture<? extends T> x,
>>                                        BiFunction<? super T,? super T, ?
>> extends U> fn);
>
> Thinking a little more about this one, fn should be a Function not a BiFunction
> given that only one of the two completables needs to complete.

Yes, thanks. (I fixed this before but then overwrote with old version; oops.)

>>     /**
>>      * Returns the value if completed, else the given valueIfAbsent.
>>      */
>>     public T getNow(T valueIfAbsent);

> still think it should use a supplier as parameter and not the value.


The motivating use case is to allow simplification of
polling-like constructions where you'd otherwise need to
first check isDone, and then get(), but could replace with:
   while(t.getNow(NOTREADY) == NOTREADY) { doSomethingElse(); }
in which case trapping into a function is not at all helpful.
And I can't think of other cases not involving plain get()
where this method is of much use.

-Doug