StructuredExecutor API and wildcards
Remi Forax
forax at univ-mlv.fr
Sun Nov 21 18:02:45 UTC 2021
I've noticed that the current API has some signatures that are not correct,
either a widlcard is missing, or there is a type parameter instead of a wildcard, etc.
I know that the Executor/Future has similar issues so there is perhaps a weird tradition ... sorry kidding.
In StructuredExecutor:
<V> Future<V> fork(Callable<V> task)
should be
<V> Future<V> fork(Callable<? extends V> task).
For all functional interface, the result should be ? extends R and the parameters should be ? super P.
For the other fork(), you can see that someone struggle to get the correct signature :)
<U, V extends U> Future<V> fork(Callable<V> task, BiConsumer<StructuredExecutor,Future<U>> onComplete)
It should be
<V> Future<V> fork(Callable<? extends V> task, BiConsumer<? super StructuredExecutor, ? super Future<V>> onComplete)
U does need to be named, Future<V> can be a Future<? extends V> because there is no methods taking a V as parameter,
but given that FutureTask has methods that takes a V, so i think it's better to keep Future invariant.
In ShutdownOnFailure,
usually we use Void instead of Object to represent the type of a value that can only be null, so
the class should be declared
class ShutdownOnFailure implements BiConsumer<StructuredExecutor,Future<Void>> { }
so
void accept(StructuredExecutor executor, Future<Object> future)
is now
void accept(StructuredExecutor executor, Future<Void> future)
and
<X extends Throwable> void throwIfFailed(Function<Throwable, ? extends X> esf)
should be
<X extends Throwable> void throwIfFailed(Function<? extends Throwable, ? extends X> esf)
In ShutdownOnSuccess<V>
<X extends Throwable> V result(Function<Throwable, ? extends X> esf)
should be
<X extends Throwable> V result(Function<? super Throwable, ? extends X> esf) throws X
for ShutdownOnSuccess<V>, i think it's better to just have a method that returns a Future instead of trying to invent another API very similar to Future.
regards,
Rémi
More information about the loom-dev
mailing list