[
https://issues.apache.org/jira/browse/GROOVY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15447137#comment-15447137
]
Paul King commented on GROOVY-7037:
-----------------------------------
+1 for Jochen's workaround in your case.
I don't believe this is a regression. I tried the above examples on 1.8.9 and
get the same behavior.
The wrapping behavior seems very old too - before my time with Groovy it
appears. Looking through history there seems like a very old syntax {{s[1:2]}}
that was changed to allow either {{s[1,2]}} or {{s[1..2]}}. The former being
wrapped into a list, the latter not since it is already a list. I believe to
support fragments like:
{code}
def s = 'elephant'.toList()
assert s[7,5,1,1].join() == 'tall'
assert s[5..7].join() == 'ant'
{code}
> getAt as Operator Throws if given Fixed and Variable Arguments
> --------------------------------------------------------------
>
> Key: GROOVY-7037
> URL: https://issues.apache.org/jira/browse/GROOVY-7037
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.3.6, 2.4.0-beta-2
> Environment: RHEL 6.5 x64
> Reporter: Steve Amerige
> Priority: Minor
> Attachments: Test.groovy
>
>
> The getAt method for indexing fails when variable arguments are used with []
> if any fixed arguments are present. For example:
> {code}
> class Test
> {
> def getAt(String s) { return s }
> def getAt(String s, Integer x) { return "$s $x" }
> // def getAt(Object... o) { return o } // This would succeed
> def getAt(String s, Object... a) { return "$s $a" }
> static void main(String[] args)
> {
> Test t = new Test()
> assert t['a'] == 'a'
> assert t['b', 2] == 'b 2'
> assert t.getAt('c', 3, true) == 'c [3, true]'
> assert t['c', 3, true] == 'c [3, true]' // This throws an exception
> }
> }
> {code}
> The above produces:
> {noformat}
> Exception thrown
> java.lang.IllegalArgumentException: wrong number of arguments
> at Test.main(ConsoleScript42:14)
> {noformat}
> Workaround: do not use fixed and variable arguments at the same time and use
> only variable arguments as in the case shown commented out above:
> getAt(Object... o). This is less-than desirable, however, because it
> restricts the user from using method overloading to separate out
> distinctly-different logic and forces the user to do runtime checks and
> implement control structure when using the single varargs method. In this
> case, however, the bug severity is mitigated by the fact that the user can
> explicitly use the "getAt" invocation instead of using the [ ] operator
> notation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
