On 02/13/2015 04:18 PM, David M. Lloyd wrote:
On 02/13/2015 09:15 AM, Peter Levart wrote:
On 02/13/2015 03:22 PM, Paul Sandoz wrote:
>It*is* inconvenient for the user to have to use wildcards in
specifying types:
>
>CompletableFuture<? extends Process> cf =
process.completableFuture();
>
>...but it doesn't hinder the use of above 'cf' quite so much as
'len' in List example above, since 'T' in CompletableFuture<T> is
used mostly in co-variant positions. The only methods that use it
in contra-variant positions are:
>
>cf.getNow(?);
>cf.complete(?);
>cf.obtrudeValue(?);
>
What about the methods with a parameter type of:
CompletionStage<? extends T>
such as applyToEither and acceptEither?
Paul.
Oh, I see.
That's a problem, yes. And these two methods are actually very useful in
the context of processes - waiting for 1st of two processes to finish.
So the signature can only be the following:
CompletableFuture<ProcessHandle> completableFuture();
I hesitate to mention it, but as someone who has been frustrated by
this same problem on numerous occasions I feel I must suggest that
maybe... having a completableFuture method should just be dropped? A
user should be able to implement it themselves fairly easily, right?
And they'd be able to sidestep problems like stack size and so on by
managing their own threads.
That's a good idea. If the following two methods were added to
Process[Handle]:
public class ProcessHandle {
public ProcessHandle waitForUninterruptibly();
}
public class Process extends ProcessHandle {
@Override
public Process waitForUninterruptibly();
}
One could get CompletableFuture(s) simply by:
ProcessHandle ph = ...;
CompletableFuture<ProcessHandle> phf =
CompletableFuture.supplyAsync(ph::waitForUninterruptibly);
Process p = ...;
CompletableFuture<Process> pf =
CompletableFuture.supplyAsync(p::waitForUninterruptibly);
Peter
