When a Map is the first parameter, it acts as a collector for any named
parameters.
def foo(Map a, b, c) {
// ...
}
foo(a:'a', 'b', 'c', x: 'also a')
________________________________
From: [email protected] <[email protected]>
Sent: Friday, April 11, 2025 9:16 AM
To: Groovy_Developers <[email protected]>
Subject: [EXT] Re: Lists in annotations
External Email: Use caution with links and attachments.
P.S. Sorry I see I forgot to add the test for the seconds case (caller side
Map, no such thing at the receiver):
===
1054 ocs /tmp> <q.groovy
def foo(a, b, c) {
println "a:$a b:$b c:$c"
}
foo([a:1], 'Hi', 'there')
1055 ocs /tmp> /usr/local/groovy-4.0.25/bin/groovy q
a:[a:1] b:Hi c:there
1056 ocs /tmp>
===
On 11. 4. 2025, at 16:12, [email protected]<mailto:[email protected]> wrote:
Christopher,
On 11. 4. 2025, at 15:55, Christopher Smith
<[email protected]<mailto:[email protected]>> wrote:
I personally find it surprising and confusing that arguments are implicitly
collected in method calls; I recently was baffled until I realized that the Map
as a first argument was causing Groovy to group the leading arguments.
I am not sure what this means. What is a “leading argument”? Can you please
show an example? With my testing, nothing is grouped (unless one uses named
arguments, which of course go into that Map):
===
1052 ocs /tmp> <q.groovy
def foo(Map m=null, a, b, c) {
println "m:$m a:$a b:$b c:$c"
}
foo('Hi', 'there', '!')
1053 ocs /tmp> /usr/local/groovy-4.0.25/bin/groovy q
m:null a:Hi b:there c:!
1054 ocs /tmp>
===
I appreciate Groovy's syntactic sugar for clear cases (such as trailing
lambdas), but I would rather not have arguments collected if the signature
isn't varargs.
Unless you limit your code by CompileStatic, that's technically impossible,
since normally caller does not (need to) know the signature of the receiver
until actually called.
All the best,
OC
On Fri, Apr 11, 2025, 05:22 Paul King
<[email protected]<mailto:[email protected]>> wrote:
I think it is just the case that Java supports only a single value or
array notation, so that's what we did too (just adapting to Groovy
array/list notation).
We have certainly had folks ask if we could also support the curly
brace syntax but that clashes with a closure.
It would be interesting to see whether it is a simple or ugly change
at the grammar/early parsing level.
Cheers, Paul.
On Fri, Apr 11, 2025 at 7:19 PM Gianluca Sartori
<[email protected]<mailto:[email protected]>> wrote:
>
> Hi folks,
>
> we use the following well known annotation in our Grails controllers:
>
> @Secured(['ROLE_USER', 'ROLE_OTHER'])
>
> I was wondering why we cannot write this instead:
>
> @Secured('ROLE_USER', 'ROLE_OTHER')
>
> like in method calls.
>
> To your knowledge is that a Groovy thing or it lies somewhere else?
>
> Cheers,
> Gianluca Sartori
>
