[
https://issues.apache.org/jira/browse/GROOVY-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17037282#comment-17037282
]
mgroovy commented on GROOVY-8580:
---------------------------------
* If this has not yet been decided, I have one more (very practical) point to
add to the (admittedly imho stronger) points I tried to malke on the mailing
list:
* I use a lot of @CompileStatic and code which looks like (I use final here of
course, but the same argument goes of course for var):
{code:java}
final t = createPersonTable() // returns PersonTable instance which is a Table
final foreignId = retrieveForeignId(t) // <T extends Table> Number
retrieveForeignId(T t)
{code}
* Code like that often does not compile under @CompileStatic, if
retrieveForeignId is a method taking a generic argument, since the type of t is
Object, and the compiler (incorrectly) rejects the call
* If I give the type of t explicitly as PersonTable then the code compiles
* This is evidently something that could be fixed in the @CompileStatic parts
of Groovy, but I guess the effort for that would be high, since it ionvolves
generics
* If, however, the type of t would be PersonTable as I suggest final/var
should behave, then (as an added benefit to all the others) this problem could
be avoided
> CLONE - Support `var` keyword of Java10 (finalise behavior of keyword under
> @CompileStatic)
> -------------------------------------------------------------------------------------------
>
> Key: GROOVY-8580
> URL: https://issues.apache.org/jira/browse/GROOVY-8580
> Project: Groovy
> Issue Type: New Feature
> Reporter: Daniel Sun
> Priority: Blocker
> Fix For: 4.x
>
>
> As part of GROOVY-8498 there is now support for the {{var}} keyword to
> provide compatibility with:
> http://openjdk.java.net/jeps/286 (Java 10)
> http://openjdk.java.net/jeps/323 (targeted for Java 11)
> For dynamic Groovy, {{var}} is an alias for {{def}}. Under
> {{@CompileStatic}}, there are three fairly obvious potential behaviors that
> could make sense for Groovy:
> * a direct alias for {{def}} in which case normal Groovy flow typing would
> apply (this is currently what is implemented but is more flexible than what
> Java developers might expect)
> * similar to the alias for {{def}} in that it allows the inferred type to
> change as further instructions are executed but it would only be allowed to
> change to sub-types of the initially inferred type (needs further
> investigation but if possible would combine some of the nice aspects of
> Groovy def and Java var behavior)
> * a direct equivalent of Java (this would be the most work and would differ
> greatly from Groovy behavior and in general would be hard to marry up with
> Groovy semantics)
> We need to finalize the behavior we want before releasing non-alpha versions
> of Groovy 3.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
