[
https://issues.apache.org/jira/browse/GROOVY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15446375#comment-15446375
]
Jochen Theodorou commented on GROOVY-7037:
------------------------------------------
I think the error is actually in getAt the list wrapping was done because back
then we did not support vargs. I was not aware of the list wrapping here at
all. So to me the real error is the list wrapping and then method matching, and
depending on the automated list unwrap of Groovy. And the part to fix is the
list wrapping imho. This would be a breaking change of course. There is a
workaround for the problem I would like to propose:
{code}
def getAt(List l){ this.getAt(*l) }
{code}
this will call getAt again, as normal method, so it will properly dispatch for
you. The method would be called for any getAt with more than one argument. A
warning though, if you want to have a getAt that reacts to list, you will have
to have that logic here as well. And if you have a list containing itself, this
will probably result in a stack overflow
> 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)
