You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Paul King (JIRA)" <ji...@apache.org> on 2019/05/06 11:49:00 UTC

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

    [ https://issues.apache.org/jira/browse/GROOVY-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833729#comment-16833729 ] 

Paul King commented on GROOVY-8943:
-----------------------------------

The type checker was indeed finding the int method but then marking it as inaccessible doing some further getAt processing (needed for maps mainly). It was getting confused when the map access was occurring within a static method even when on a local variable.

> @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
>            Priority: Major
>
> 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)