CompletableFuture
Doug Lea
dl at cs.oswego.edu
Tue Nov 27 16:11:34 PST 2012
On 11/27/12 17:01, Remi Forax wrote:
>
> here is the version with the wildcards :)
Thanks!
> public <U,V> CompletableFuture<V> and(CompletableFuture<? extends U> x,
> BiFunction<? super T,? super U,? extends V> fn);
>
> ... public <U> CompletableFuture<T> and(CompletableFuture<? extends U> x,
> BiBlock<? super T, ? super U> action);
>
> Also, I think that we decided (correct me if I'm wrong) to not use the
> result type of a lambda to disambiguate overloads, so
> completable.and(completable2, (a,b) -> foo(a, b)) is ambiguous.
Could be. Sam worried about this too.
Both of the workarounds are less than beautiful.
1. Support function (not action) versions only, in which case people will
need to use Function<T,Void> and return null for the common case
of actions, not functions.
2. Differentiate by method name. Nothing really good came to mind
(which is why I overloaded them to begin with). But maybe something
will occur to us.
>> /**
>> * Whether or not already completed, sets the value returned by
>> * subsequent invocations of get() and related methods to the
>> * given value.
>> */
>> public void force(T value);
>
> The semantics of complete and force regarding thread that is already waiting on get() is not clear for me.
Thanks. Rewording to get the "subsequently" in the right place:
/**
* Whether or not already completed, sets the value subsequently
* returned by method get() and related methods to the given
* value.
*/
-Doug
More information about the lambda-libs-spec-observers
mailing list