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.
--
- DML
