@unless you reassign, you would not notice the difference between current def and the Java var:1) If I don't need to reassign, I would use final instead of var :-)2) Supporting var for fields that get initialized during declaration, also would feel very Groovy to me, although I personally would not expect to use that a lot. -------- Ursprüngliche Nachricht --------Von: Jochen Theodorou <[email protected]> Datum: 08.03.18 04:50 (GMT+01:00) An: [email protected] Betreff: Re: About supporting `var` of Java10+ On 08.03.2018 02:23, MG wrote: > 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 the static compiler in Groovy we have Foo x = new SubClassOfFoo() x is seen as a type with a declaration type of Foo, with the current compile time type of SubClassOfFoo. Here x = 1 is then not allowed, because Integer is no subclass of Foo. But you are allowed to call methods on x, that are defined only on SubClassOfFoo. The "catch em all" superclass is of course Object: Foo x = ... x = 1 // compile error Object x = new Foo() x = 1 // no compile error In that sense "def" is just an alias for Object and has zero special logic. Obviously we just have to set declaration type = current compile time type to get something, which is very near to the planed var in Java. But this requires more than just changing the parser. This requires something I can recognize as "var", to then apply the special logic in the static compiler. > 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. unless you reassign, you would not notice the difference between current def and the Java var, except for fields, but afaik there is no var allowed. bye Jochen
