Hi Paul,
Updated Webrev to use List<ProcessHandle> instead of ProcessHandle...
varargs.
http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8132394/
comments below...
On 11/10/2015 4:49 AM, Paul Sandoz wrote:
On 9 Nov 2015, at 19:55, Roger Riggs <roger.ri...@oracle.com> wrote:
Hi Paul, Alan,
What are the chances that varargs will be updated at some point in the future
to use
Lists instead of arrays? It would be a bit of thrash to try to avoid varargs
if varargs
is likely to be updated. It is a bit awkward at the moment though.
I'd hope that at some point varargs caller syntax could handle automatically
the case where the method
invoked accepts either a List<T> or T[]. Currently, providing a T[] is able to
use the array as is.
It would make sense that it could also convert a List<T> to T[] as part of code
generation.
For the existing Arrays.asList( pb1, pb2) or JEP 269 List.of(pb1, pb2) force
the developer to
type extra stuff and create more objects than the current varargs usage.
Not necessarily, it depends on the literal size. Recall that varargs packs the
elements into T[]. For a small number of elements a factory method can pack the
elements into a List impl without an internal array. And for this case it’s all
in the a wash giving the forking of processes.
I was focused more on the developer having to know and explicitly create
a List.
The simple cases are likely to be inline and varargs is a better match
for that.
Without the proposed JEP 269 List convenience methods, working with
lists is quite verbose
unless the program data model is actually dealing with lists.
But List is a more robust encapsulation and has fewer implementation
issues.
Where is varargs going?
Nowhere :-) I doubt varargs is going to be replaced, and the convenience
collection factories will use it too. There would likely be circular
dependencies and backwards compatibility issues and we would need to work out
some sort of bridge mechanism. What we need for better varargs support is
frozen arrays, and superior auto-unboxing/eliding optimizations if things
inline.
I like varargs! it’s very convenient, it’s great for small literal expressions,
but one can quickly rub up against it. List is more easily composable than
varargs.
I have run up against it many times with:
public static CompletableFuture<Void> allOf(CompletableFuture<?>... cfs) {
public static CompletableFuture<Object> anyOf(CompletableFuture<?>... cfs) {
Accepting a Collection<?> would have overall been more convenient to me. In
fact i should propose such additions to CF :-)
Having both varargs and List would be acceptable (as is the case for
MethodType). But if there is to be only one i would choose List.
I'm not sure pipelines will be used enough to warrant extra convenience
methods, not to mention
twice as many tests. So the more general List<ProcessBuilder> is better
to start with.
Thanks, Roger
[old webrev] http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8132394-v1
And, will List<T> toArray() ever be able to properly create T[]?
That may be possible, there is an issue tracking this, it keeps getting bumped
down in the the priority list of things to do.
:(
Paul.
