[jira] [Resolved] (GROOVY-8943) @CompileStatic with getAt(int) and getAt(String)

["Paul King (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King resolved GROOVY-8943.
-------------------------------
       Resolution: Fixed
         Assignee: Paul King
    Fix Version/s: 2.5.7
                   3.0.0-beta-1

Should be fixed. Thanks for spotting the issue!

> @CompileStatic with getAt(int) and getAt(String)
> ------------------------------------------------
>
>                 Key: GROOVY-8943
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8943
>             Project: Groovy
>          Issue Type: Improvement
>            Reporter: Endre Stølsvik
>            Assignee: Paul King
>            Priority: Major
>             Fix For: 3.0.0-beta-1, 2.5.7
>
>
> It seems like if I use @CompileStatic, a construct like
> {code:java}
> Car specificCar = somethingWithAGetAtMethod[129]
> .. or ..
> Car specificCar = somethingWithAGetAtMethod["AZ1235"]
> {code}
> doesn't work. The compiler says: Groovyc: [Static type checking] - Cannot assign value of type java.lang.Object to variable of type com.example.Car
> This seems strange. The getAt(..)-method in question obviously return a "Car" here.
> This email thread has evidently experienced the same: [http://groovy.329449.n5.nabble.com/Unexpected-behaviour-for-getAt-operator-operloading-with-static-compilation-td5744122.html]
> .. and the theory is that since this is specified on Groovy's extension of Object, which specifies Object getAt(String), then that might be the culprit. Interesting, though, that Object does not seemingly specify getAt(int), but it still gives the exact same compiler error with both int and String.
> I had this idea that the subscript-operator was "syntactic sugar", which then makes the compiler error hard to understand.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)