As @21Solutions already mentioned, Java’s varargs must be the last argument in the list so your example is wrong. It would need to be:
function test( String msg, MyCFC... mycfcs ) { ... }
This would be a function that takes a string arguments followed by zero or more MyCFC
arguments:
test("one");
test("two", cfc1);
test("three", cfc1, cfc2);
test("four", cfc1, cfc2, cfc3);
and inside test
there would be just two arguments with the types String
and MyCFC[]
respectively.
In CFML today we’d have to do:
function test( String msg, MyCFC[] mycfcs ) { ... }
This would be a function that takes a string arguments followed by an array containing zero or more MyCFC
arguments:
test("one",[]);
test("two", [cfc1]);
test("three", [cfc1, cfc2]);
test("four", [cfc1, cfc2, cfc3]);
I’m not convinced that the variadic format is worth the effort. It can be confusing (your function calls seem to have an arbitrary number of arguments, your function itself only has one or two arguments – and the “arrayness” of the last argument is implicit) – and CFML already allows arbitrary arguments to function calls and provides a full arguments
vector containing them all. You could argue “But the Java style gives you type checking!” which is true but mostly irrelevant: you could do type checking at run time if you wanted, or you could just interact with the argument values and let the CFML runtime trap any type errors (CFML is a dynamically typed language – it is not Java).
Java is actually worse in some ways, because when you want a variadic non-homogenous argument list, Java forces you to use Object...
and then perform dynamic type checking and down-casting at runtime anyway! So you’re often forced to lose what little type safety Java provides and then you have to write extra code, compared to CFML, to “do the right thing” with your now-generic Object
types!