You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Gianluca Sartori <g....@gmail.com> on 2025/04/11 09:18:43 UTC
Lists in annotations
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
Re: [EXT] Re: Lists in annotations
Posted by "Milles, Eric (TR Technology) via dev" <de...@groovy.apache.org>.
Just an FYI, the support for @A({ ... }) is tracked by https://issues.apache.org/jira/browse/GROOVY-11492
________________________________
From: Paul King <pa...@asert.com.au>
Sent: Friday, April 11, 2025 5:20 AM
To: dev@groovy.apache.org <de...@groovy.apache.org>
Subject: [EXT] Re: Lists in annotations
External Email: Use caution with links and attachments.
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 <g....@gmail.com> 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
>
Re: [EXT] Lists in annotations
Posted by "ocs@ocs.cz" <oc...@ocs.cz>.
Sure, I mentioned that (“unless one uses named arguments, which of course go into that Map” below).
Also, collecting the named arguments in this Map is — far as I know, at least — the only possible way to use them at all. If there is no callable method with a first Map (or Object) argument and the caller uses named arguments, at the moment of call, MissingMethodException would be thrown.
Thanks,
OC
> On 11. 4. 2025, at 16:19, Milles, Eric (TR Technology) via dev <de...@groovy.apache.org> wrote:
>
> 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: ocs@ocs.cz <oc...@ocs.cz>
> Sent: Friday, April 11, 2025 9:16 AM
> To: Groovy_Developers <de...@groovy.apache.org>
> 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, ocs@ocs.cz <ma...@ocs.cz> wrote:
>>
>> Christopher,
>>
>>> On 11. 4. 2025, at 15:55, Christopher Smith <chrylis+groovy@gmail.com <ma...@gmail.com>> 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 <paulk@asert.com.au <ma...@asert.com.au>> 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 <g.sartori@gmail.com <ma...@gmail.com>> 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
>>> >
>>
>
Re: [EXT] Re: Lists in annotations
Posted by "Milles, Eric (TR Technology) via dev" <de...@groovy.apache.org>.
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: ocs@ocs.cz <oc...@ocs.cz>
Sent: Friday, April 11, 2025 9:16 AM
To: Groovy_Developers <de...@groovy.apache.org>
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, ocs@ocs.cz<ma...@ocs.cz> wrote:
Christopher,
On 11. 4. 2025, at 15:55, Christopher Smith <ch...@gmail.com>> 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 <pa...@asert.com.au>> 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 <g....@gmail.com>> 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
>
Re: Lists in annotations
Posted by "ocs@ocs.cz" <oc...@ocs.cz>.
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, ocs@ocs.cz wrote:
>
> Christopher,
>
>> On 11. 4. 2025, at 15:55, Christopher Smith <chrylis+groovy@gmail.com <ma...@gmail.com>> 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 <paulk@asert.com.au <ma...@asert.com.au>> 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 <g.sartori@gmail.com <ma...@gmail.com>> 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
>> >
>
Re: Lists in annotations
Posted by "ocs@ocs.cz" <oc...@ocs.cz>.
Christopher,
> On 11. 4. 2025, at 15:55, Christopher Smith <ch...@gmail.com> 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 <paulk@asert.com.au <ma...@asert.com.au>> 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 <g.sartori@gmail.com <ma...@gmail.com>> 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
> >
Re: Lists in annotations
Posted by Paul King <pa...@asert.com.au>.
I'd raise a separate thread since this is now off-topic for the
original thread. But, yes, the JDK doesn't have native support for
named arguments, so if you use named arguments, some argument
collecting will occur. The map, as first parameter, is the
well-documented approach we use for Java integration purposes. If you
have a case where given that knowledge, it is still confusing, I'd
suggest chatting in a separate thread. Perhaps I've misunderstood what
you were referring to.
On Fri, Apr 11, 2025 at 11:56 PM Christopher Smith
<ch...@gmail.com> 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 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.
>
> Christopher Smith
>
> On Fri, Apr 11, 2025, 05:22 Paul King <pa...@asert.com.au> 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 <g....@gmail.com> 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
>> >
Re: Lists in annotations
Posted by Christopher Smith <ch...@gmail.com>.
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 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.
Christopher Smith
On Fri, Apr 11, 2025, 05:22 Paul King <pa...@asert.com.au> 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 <g....@gmail.com>
> 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
> >
>
Re: Lists in annotations
Posted by Paul King <pa...@asert.com.au>.
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 <g....@gmail.com> 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
>