[
https://issues.apache.org/jira/browse/GROOVY-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Endre Stølsvik updated GROOVY-8943:
-----------------------------------
Description:
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.
was:
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.SomethingWithAGetAtMethod
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.
> @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)
