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
> <dev@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: o...@ocs.cz <o...@ocs.cz>
> Sent: Friday, April 11, 2025 9:16 AM
> To: Groovy_Developers <dev@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, o...@ocs.cz <mailto:o...@ocs.cz> wrote:
>>
>> Christopher,
>>
>>> On 11. 4. 2025, at 15:55, Christopher Smith <chrylis+gro...@gmail.com
>>> <mailto:chrylis+gro...@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
>>> <mailto: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.sart...@gmail.com
>>> <mailto:g.sart...@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
>>> >
>>
>
