You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Daniel Sun <re...@hotmail.com> on 2018/03/07 23:53:57 UTC
About supporting `var` of Java10+
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
Re: About supporting `var` of Java10+
Posted by Daniel Sun <re...@hotmail.com>.
Thanks for your reviewing the RI.
The following code is truely allowed in Groovy, fewer limitation than Java
10+. So we can think the current RI as a enhanced implementation for `var`
;-)
```
var myVar = new Foo()
myVar = 123
```
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About supporting `var` of Java10+
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jochen,
> 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.
OK. I see :-)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About supporting `var` of Java10+
Posted by mg <mg...@arscreat.com>.
@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 <bl...@gmx.org> Datum: 08.03.18 04:50 (GMT+01:00) An: dev@groovy.apache.org 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
Re: About supporting `var` of Java10+
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Re: About supporting `var` of Java10+
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
We treat `var` as an alias of `def` with some limitations.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About supporting `var` of Java10+
Posted by Jesper Steen Møller <je...@selskabet.org>.
Yes, I see it now.
I implemented 'var' for Eclipse's Java compiler, but did it without changing the grammar, so when I saw you'd changed the grammar, I wrongly assumed you hadn't thought of it.
-Jesper
Re: About supporting `var` of Java10+
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
Groovy already supports `int var = 10;` ;-)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About supporting `var` of Java10+
Posted by mg <mg...@arscreat.com>.
So you could sayvar var = new Varchar();-)
-------- Ursprüngliche Nachricht --------Von: Jesper Steen Møller <je...@selskabet.org> Datum: 08.03.18 07:50 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: About supporting `var` of Java10+
Hi list
It’s not a keyword in Java 10, it’s just a reserved identifier. In other words, “int var = 10;” is still legal.
I’m thinking we should remain as conservative as Java in those matters.
-Jesper
> On 8 Mar 2018, at 02.23, MG <mg...@arscreat.com> 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 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
>>
>
Re: About supporting `var` of Java10+
Posted by Jesper Steen Møller <je...@selskabet.org>.
Hi list
It’s not a keyword in Java 10, it’s just a reserved identifier. In other words, “int var = 10;” is still legal.
I’m thinking we should remain as conservative as Java in those matters.
-Jesper
> On 8 Mar 2018, at 02.23, MG <mg...@arscreat.com> 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 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
>>
>
Re: About supporting `var` of Java10+
Posted by MG <mg...@arscreat.com>.
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
>
Re: About supporting `var` of Java10+
Posted by "Daniel.Sun" <su...@apache.org>.
As a side note, `var` of Java10+ supports the following usage[1]:
```
var person = new Object() {
String name = "bob";
int age = 5;
};
System.out.println(person.name + " aged " + person.age);
```
Cheers,
Daniel.Sun
[1]
http://benjiweber.co.uk/blog/2018/03/03/representing-the-impractical-and-impossible-with-jdk-10-var/
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html