groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: About supporting `var` of Java10+
Date Thu, 08 Mar 2018 01:23:42 GMT
Hi Daniel,

I agree that it does not make much sense to closely mirror the details 
of the Java specifications in Groovy, but I still think that simply 
treating var the same as def looses some potential for the static 
compilation case, e.g.:
var myVar = new Foo()
myVar = 123 // Allowed when var === def, forbidden if myVar has type Foo

For different reasons (scenarios where reflection on classes is used, 
such as in my library), the same goes for
final myField = new Foo() // myField should have type Foo

As http://openjdk.java.net/jeps/286  correctly mentions, type inference 
is not magic, but in my mind this comes down to a 90+% solution again, 
namely that covering the two cases:
1) var myVar = new Foo()  // myVar  is of type Foo
2) var myVar = myMethod() // myVar is of return type of myMethod
will cover a lot of ground, and I therefore believe it would be ok to 
fall back to var/final === def in all other cases for now. If someone 
wants to / has time, he can improve on this later.

My 8.05762816 Cent,
mg


On 08.03.2018 00:53, Daniel Sun wrote:
> Hi all,
>
>      As GROOVY-8498[1] describes as follows, in order to compatibility with
> Java 10+, Groovy should support `var` the reserved type name. The reference
> implementation has been pushed to master and 2.6.0 branch, you can find it
> via the link[2].
>
>     Any thoughts?
>
> *GROOVY-8498:*
> ```
> This is to provide compatibility with:
> http://openjdk.java.net/jeps/286 (Java 10)
> http://openjdk.java.net/jeps/323 (targeted for Java 11)
>
> Java 10 provides var to allow reduced ceremony by avoiding manifest
> declaration of types for local variables for cases where type inferencing
> can be supported. Groovy already does this with "def" and has it's own
> approach for type inferencing within type-checked/compile static code. With
> this in mind, it seems to make most sense for Groovy to have "var" as an
> alias for "def" rather than closely mimic only the use cases allowed by
> Java.
> ```
>
> Cheers,
> Daniel.Sun
>
> [1] https://issues.apache.org/jira/browse/GROOVY-8498
> [2]
> https://github.com/apache/groovy/commit/f30741f519f4012c7cca3959ade9e4ec12625e45
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>


Mime
View raw message