About supporting `var` of Java10+

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
33 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

Jochen Theodorou


Am 08.03.2018 um 09:44 schrieb mg:
> @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.

they decided against using final and instead go with semi-final.

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

paulk_asert
What are peoples thoughts. Should we try to make "def" and "var" exactly aliases? Or almost?
If we do, we need to add some info in the differences from Java section of the doco to explain the differences with Java's upcoming "var".
If we don't, we need to articulate some good reasons for making the distinction.
I am leaning slightly towards the former but I can see arguments for both sides. In any case I am interested in others thoughts.
At a minimum, I'd like to see both ""def" and "var" recognised as reserved type names in the grammar rather than keywords.
Any thoughts?


Cheers, Paul.


On Thu, Mar 8, 2018 at 7:57 PM, Jochen Theodorou <[hidden email]> wrote:


Am 08.03.2018 um 09:44 schrieb mg:
@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.

they decided against using final and instead go with semi-final.

bye Jochen

MG
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

MG
In reply to this post by Jochen Theodorou
Maybe I am missing your point, but what I meant was: When I use

var x = new Foo()

I indicate that x will be reassigned further down in the scope, otherwise I use

final x = new Foo()

PS: I know all the Groovy samples in the documentation use def instead of final all the time, even though no reassignment takes place. Evidently I do not agree with that - even where final is not really enforced by Groovy, the documentation aspect remains (and at least Intellisense will warn you when reassigning to a final field/variable/parameter) :-)


-------- Ursprüngliche Nachricht --------
Von: Jochen Theodorou <[hidden email]>
Datum: 08.03.18 10:57 (GMT+01:00)
Betreff: Re: About supporting `var` of Java10+



Am 08.03.2018 um 09:44 schrieb mg:
> @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.

they decided against using final and instead go with semi-final.

bye Jochen
MG
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

MG
In reply to this post by paulk_asert
Hi Paul,

I would be interested to hear if you see some advantages of going down the
#define var def
route - apart from the obvious, that it is the easiest/fastest to implement ?

Cheers,
mg

-------- Ursprüngliche Nachricht --------
Von: Paul King <[hidden email]>
Datum: 08.03.18 12:26 (GMT+01:00)
Betreff: Re: About supporting `var` of Java10+

What are peoples thoughts. Should we try to make "def" and "var" exactly aliases? Or almost?
If we do, we need to add some info in the differences from Java section of the doco to explain the differences with Java's upcoming "var".
If we don't, we need to articulate some good reasons for making the distinction.
I am leaning slightly towards the former but I can see arguments for both sides. In any case I am interested in others thoughts.
At a minimum, I'd like to see both ""def" and "var" recognised as reserved type names in the grammar rather than keywords.
Any thoughts?


Cheers, Paul.


On Thu, Mar 8, 2018 at 7:57 PM, Jochen Theodorou <[hidden email]> wrote:


Am 08.03.2018 um 09:44 schrieb mg:
@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.

they decided against using final and instead go with semi-final.

bye Jochen

MG
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

MG
In reply to this post by Jesper Steen Møller
So you could say
var var = new Varchar()
;-)

-------- Ursprüngliche Nachricht --------
Von: Jesper Steen Møller <[hidden email]>
Datum: 08.03.18 07:50 (GMT+01:00)
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 <[hidden email]> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

Jochen Theodorou
In reply to this post by Daniel Sun


Am 08.03.2018 um 12:45 schrieb mg:
> Maybe I am missing your point, but what I meant was: When I use
>
> var x = new Foo()
>
> I indicate that x will be reassigned further down in the scope,
> otherwise I use
>
> final x = new Foo()

That's what I understood. But the later variant is not part of the JEP.
In Groovy what you wrote is an alias for final Object x = new Foo()

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

paulk_asert
In reply to this post by paulk_asert

On Thu, Mar 8, 2018 at 9:53 PM, mg <[hidden email]> wrote:
Hi Paul,

I would be interested to hear if you see some advantages of going down the
#define var def
route - apart from the obvious, that it is the easiest/fastest to implement ?

I am not too worried about ease/speed of implementation but I think we have to be on a continual quest for simplification.
So for "def"/"var" if we just decide things organically as we go we might end up with numerous differences:
* one is a keyword, one is a reserved type name
* one is allowed as a variable name, the other not
* one is allowed to declare methods, the other not
* one is allowed for class names, the other not
* one is allowed for package names, the other not
* one is allowed as a direct key for a map, the other not
and so forth.
And then that complexity travels throughout the code base multiplying against the other orthogonal axes where differences occur.
Before we know it we can end up with an explosion of complexity that has to be maintained.

But also, if we want to make Groovy Java "var" friendly, what simple explanation can we give
knowing that Groovy is a different language to Java?
For dynamic Groovy, it can't really mean much different to "def" (effectively Object).
Java is introducing "var" it to reduce ceremony for local variables, i.e. maximise type inferencing.
However, that is what we already do (albeit backed by a flow typing semantics different to Java)
when we use "def" and @CompileStatic or @TypeChecked. So, I can see good points for just making
one an alias of the other. It would mean allowing a few ugly corner cases like "def def" (currently not
allowed) and "var var" but you could check against such cases with a Codenarc rule. And as it turns
out, isn't too much to implement.

The argument on the flip side is fairly simple too. We have two names, we can use those to
represent two different concepts. Even Java considered different names:
let, val, auto, const, or final, instead of or in conjunction with var. But given what they have
decided - a semantics very close to our "def" - I can't see what difference we can now make
of the other name - apart from the obvious difference of limiting it to places where Java
would use it, i.e. limit it to just local vars and perhaps just within @CompileStatic annotated
nodes. But I don't see any value in those limitations.

Cheers, Paul.
 
-------- Ursprüngliche Nachricht --------
Von: Paul King <[hidden email]>
Datum: 08.03.18 12:26 (GMT+01:00)
Betreff: Re: About supporting `var` of Java10+

What are peoples thoughts. Should we try to make "def" and "var" exactly aliases? Or almost?
If we do, we need to add some info in the differences from Java section of the doco to explain the differences with Java's upcoming "var".
If we don't, we need to articulate some good reasons for making the distinction.
I am leaning slightly towards the former but I can see arguments for both sides. In any case I am interested in others thoughts.
At a minimum, I'd like to see both ""def" and "var" recognised as reserved type names in the grammar rather than keywords.
Any thoughts?


Cheers, Paul.


On Thu, Mar 8, 2018 at 7:57 PM, Jochen Theodorou <[hidden email]> wrote:


Am 08.03.2018 um 09:44 schrieb mg:
@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.

they decided against using final and instead go with semi-final.

bye Jochen


MG
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

MG
In reply to this post by Jochen Theodorou
My argument was not in relation to the JEP, but a Groovy user story, in relation to you saying, that I would not see a difference between def and var, apart from when assigning a value later on. 

But assigning a value later on is _exactly_ what I am going to do when I use var - because otherwise I would use final instead of var...

-------- Ursprüngliche Nachricht --------
Von: Jochen Theodorou <[hidden email]>
Datum: 08.03.18 13:32 (GMT+01:00)
Betreff: Re: About supporting `var` of Java10+



Am 08.03.2018 um 12:45 schrieb mg:
> Maybe I am missing your point, but what I meant was: When I use
>
> var x = new Foo()
>
> I indicate that x will be reassigned further down in the scope,
> otherwise I use
>
> final x = new Foo()

That's what I understood. But the later variant is not part of the JEP.
In Groovy what you wrote is an alias for final Object x = new Foo()

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

Aarjav Patel
In reply to this post by Jochen Theodorou
Hi all,

I do not know all of the intricacies in the difference between current groovy def and the proposed java var. However as a groovy 'user' coming from a Javan background, I would like or expect var in groovy to be treated/behave the same way as in java. def then would be an 'enhanced' version of var which works better (?) with other language features. This way there are less surprises when using var.

Unfortunately I have not looked at 2.5+ regarding lambdas. Are they just another way to denote a closure? Just wondering how it was handled so that maybe it can give us similar options for var/def.

Thanks,

- Aarjav

On Mar 8, 2018 8:58 AM, "mg" <[hidden email]> wrote:
My argument was not in relation to the JEP, but a Groovy user story, in relation to you saying, that I would not see a difference between def and var, apart from when assigning a value later on. 

But assigning a value later on is _exactly_ what I am going to do when I use var - because otherwise I would use final instead of var...

-------- Ursprüngliche Nachricht --------
Von: Jochen Theodorou <[hidden email]>
Datum: 08.03.18 13:32 (GMT+01:00)
Betreff: Re: About supporting `var` of Java10+



Am 08.03.2018 um 12:45 schrieb mg:
> Maybe I am missing your point, but what I meant was: When I use
>
> var x = new Foo()
>
> I indicate that x will be reassigned further down in the scope,
> otherwise I use
>
> final x = new Foo()

That's what I understood. But the later variant is not part of the JEP.
In Groovy what you wrote is an alias for final Object x = new Foo()

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: About supporting `var` of Java10+

paulk_asert
In reply to this post by Jochen Theodorou
So in that one aspect of "assigning a value later on" your expectation is exactly like Java's "var" and Groovy's current "def"?


On Thu, Mar 8, 2018 at 11:58 PM, mg <[hidden email]> wrote:
My argument was not in relation to the JEP, but a Groovy user story, in relation to you saying, that I would not see a difference between def and var, apart from when assigning a value later on. 

But assigning a value later on is _exactly_ what I am going to do when I use var - because otherwise I would use final instead of var...

-------- Ursprüngliche Nachricht --------
Von: Jochen Theodorou <[hidden email]>
Datum: 08.03.18 13:32 (GMT+01:00)
Betreff: Re: About supporting `var` of Java10+



Am 08.03.2018 um 12:45 schrieb mg:
> Maybe I am missing your point, but what I meant was: When I use
>
> var x = new Foo()
>
> I indicate that x will be reassigned further down in the scope,
> otherwise I use
>
> final x = new Foo()

That's what I understood. But the later variant is not part of the JEP.
In Groovy what you wrote is an alias for final Object x = new Foo()

bye Jochen

1234