Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

General form

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.

Variable Arguments

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.

Closures

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

See Maps
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 variabale arguments part or you can let it have its own parameter - that is for you to decide.

  • No labels