Java supports most of the signatures you know from Java. Since Groovy 1.5 Groovy supports full usage of generics in method declarations. Please see a Java tutorial for details.
I will often show a more general method signature like
This is not valid Groovy code, it is just there to show that a method named foo has n+2 parameters. Usually this means also that n could be 0. In that cae, the real resulting method signature would look like:
. A form of
would mean n+m+2 parameters. Likewise a method call
is a method call with n+1 arguments. Note also the word parameter is used when a method declaration is involved and argument is in case of method calls. I will in general use the method name foo as a placeholder for a real method name. I will use T if a certain type is required. This could be Object, a primitive type or any class you like to use.
Like Java since Java5 Groovy supports variable arguments. To use them you have to give a special method signature where the last parameter is an array.
Here foo supports n arguments by default, but also an unspecified number of further arguments exceeding n. Example
In this example we defined a method foo, that is able to take any number of arguments, including no arguments at all. args.length will then specify the number of arguments. T... is the same syntax as used in Java and is internally represented as array where the parameter has a special flag set. Groovy allows as alternative T. That means any method that has an array as last parameter is seen by Groovy as a method that takes a variable number of arguments. These methods are seen as such by Java too, since the "variable arguments flag" is set. Methods defined in Java using T... behave like a variable arguments method. Methods defined in Java using T will not have the special flag set, but Groovy will still see them as variable arguments methods.
Note: T or T... do have to be the last parameter, this clashes with Closures
If in case of def foo(T args) foo is called with null, then args will be null and not an array of length 1 with null as only element. If foo is called with an array as argument, then args will be that array instead of an array of length 1 containing the given array as only element. T... will not behave different. This is no special logic we thought of, that is how variable arguments behave in Java too.
See also Closures.
Groovy allows you to attach "blocks" to method calls like in:
To be able to attach a "block" in this way, the method signature must be
where T is Object, Closure or no explicit type. Example:
You are also allowed to use the "block" as normal argument
. If Variable Arguments and Closures are combined you will have the problem, that the closure needs to be the last argument but the parameter enabling variable arguments needs to be the last one too. You could use code like this to check at runtime:
!args will be true if args is null or an array of length 0, args-1 refers to the last element of the array.
Named arguments requires the following method signature
, but work is done by the compiler for the method call. A method call
will always be transformed to
. If you mix the positions of the pi and qi elements, then the compiler will still force the same transformed signature. Example:
The type T can be Object, Map or no explicit type. in fact other types are possible for T.. any type compatible to the Extended Guide to Method Signatures.getClass() can be used. But the type may change for example from HashMap (Groovy 1.0) to LinkedHashMap (since Groovy 1.5), so it is only safe to use the less specialized types.
Note: the map is always the first argument
Combining named arguments with closures or variable arguments is no problem. you can make the map the first element of the variable arguments part or you can let it have its own parameter - that is for you to decide.