Re: About supporting `var` of Java10+

[Daniel.Sun]

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

Re: About supporting `var` of Java10+

[MG]

On 09.03.2018 00:01, Paul King wrote:
But Java doesn't have a dynamic mode so it is difficult to offer the 
exact same behavior. We could prohibit "var" from being used in 
dynamic Groovy but users might expect to be able to cut and paste from 
Java and run in dynamic mode.


I am convinced that is what people expect, at least that was exactly 
what I did, and what I tell Java developers is so great about Groovy: 
Just start by pasting/writing Java without semicolons at the end of each 
line, and learn as you go along.
I feel I am missing something here, because where you seem to see 
problems, in my mind var "just" gets replaced by the RHS type as early 
as possible - why would this raise any problems in dynamic or static 
Groovy ?


var x = RHS

becoming

typeof(RHS) x = RHS

gives exactly what any developer who knows var would expect, no ?

Re: About supporting `var` of Java10+

[MG]

On 08.03.2018 14:13, Paul King wrote:


On Thu, Mar 8, 2018 at 9:53 PM, mg > wrote:



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:






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.


I see that argument in general, but here it seems to be mostly that 
"var" is allowed in more places than "def" - would that really lead to 
an explosion of complexity ?

Also would those differences not also exist in the var === def case ?

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).


Not true, shown by the examples in my last mail, which is completely 
dynamic Groovy: Assignment fails during runtime in var-equivalent-case, 
and works in def-case.


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)


The flow typing cannot deduce what is not expressed, in this case the 
type we want a variable to be restricted to. So var and flow typing are 
orthogonal concepts.


The argument on the flip side is fairly simple too. We have two names, 
we can use those to

represent two different concepts.


One of them being exactly the concept Java uses, the other a much more 
lenient concept coming from the dynamic part of the Groovy world.



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"


Yes, def can be used to fake var, but it is not var.
By the same argument you could ask, why Groovy supports much more 
complex (to implement and maintain) concepts such @CompileStatic and 
flow typing, when everything works exactly the same as in the dynamic 
case (i.e. dynamic Groovy code looks like static Groovy code or Java - 
but the underlying semantics are different).


In the end it boils down to: var === def would keep Groovy look and feel 
like Java, while var with Java-like semantics would do that _and_ extend 
the possibilities of Groovy developers to more easily express 
themselves. That "more" comes at a price, in current and future 
development efforts, just as any other language feature...


To me, coming more from a non-def-using, type-safe, easier-to-read-code 
perspective, I feel like it is a wasted opportunity, now that a var 
keyword is being introduced, because once var === def has been coosen, 
changing its semantics to Java-like later on would be a breaking change, 
and will therefore most likely not happen. So for all the Groovy 
developers that see Groovy as a fully blown, mostly statically typed 
language, I would ask you to reconsider :-)


mg

Re: About supporting `var` of Java10+

[MG]

Hi Paul,

1. If I will assign a value to a variable later, I would use var with
   Java semantics. Without var I give the type of the variable
   explicitely as restrictive as possible. I would not use def (I only
   use def as the return value for a method returning an anonymous
   class instance, since IntelliJ Intellisense picks up the type in
   that case, contrary to when using Object as the return type).
2. If I will not assign a value to a variable later on, I use final.

(Jochen's argument, as I understood it, was, that my idea of var (close 
to what Java will do) differs from Groovy's def only when assigning a 
value to the variable later on. To which I replied that in my book that 
is in 100% of all cases (because otherwise I use final)).


In code:

@Canonical static class FoorchterlichLongerNome { Numberx; Strings }


@Test void finalFooVarTest() {
  final x =new FoorchterlichLongerNome(123,'abc')
  println"x=$x"x =987 println"x=$x" }

Compile time error:
Error:(23, 5) Groovyc: The variable [x] is declared final but is reassigned


@Test void fooVarTest() {
  FoorchterlichLongerNome x =new FoorchterlichLongerNome(123,'abc')
  //var x = new FoorchterlichLongerNome(123,'abc') // equivalent to the 
above line in var with Java semantics println"x=$x" x =new FoorchterlichLongerNome(4567,'DEFG')

  println"x=$x"x =987 println"x=$x" }

Runtime error:
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot 
cast object '987' with class 'java.lang.Integer' to class 
'groovy.Groovy_var_keyword_Spike$FoorchterlichLongerNome'



@Test void defFooVarTest() {
  def x =new FoorchterlichLongerNome(123,'abc')
  //var x = new FoorchterlichLongerNome(123,'abc') // equivalent to the 
above line in var with Groovy def semantics println"x=$x"x =987 println"x=$x" }


Output:
x=groovy.Groovy_var_keyword_Spike$FoorchterlichLongerNome(123, abc)
x=987



On 08.03.2018 23:42, Paul King wrote:
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 <mailto:mg...@arscreat.com>> 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 mailto:blackd...@gmx.org>>
Datum: 08.03.18 13:32 (GMT+01:00)
An: dev@groovy.apache.org <mailto:dev@groovy.apache.org>
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

Re: About supporting `var` of Java10+

[Paul King]

On Fri, Mar 9, 2018 at 5:46 AM, Aarjav Patel  wrote:

> 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.
>

But Java doesn't have a dynamic mode so it is difficult to offer the exact
same behavior. We could prohibit "var" from being used in dynamic Groovy
but users might expect to be able to cut and paste from Java and run in
dynamic mode. So, I am suggesting that for dynamic mode that correct code
copied and pasted will run as expected and incorrect code will fail "as
expected" but at runtime. With the caveat being that Groovy does have some
other differences to Java which would come into play. This is how "def"
behaves now. Similarly, for static Groovy, I am suggesting "def" behavior.
This is slightly different to Java's behavior - the Groovy type checker
employ's flow typing which is a different approach to Java's but similar in
many situations. My suspicion is that if we write a second chunk of the
type checker with Java only semantics for "var", then in code with mixed
"var" and "def" definitions, it will become more difficult for programmers
to follow what is going on.

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.
>

The special lambda support is a 2.6/3 feature. It would be great to discuss
that further but it's not the topic here. In 2.5 there is no change to the
existing "lambda" support which essentially boils down to coercion of
Closures to SAM interfaces including all of those that underpin Java's
lambdas.


> Thanks,
>
> - Aarjav
>
> On Mar 8, 2018 8:58 AM, "mg"  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 
>> Datum: 08.03.18 13:32 (GMT+01:00)
>> An: dev@groovy.apache.org
>> 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
>>
>

Re: About supporting `var` of Java10+

[Paul King]

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  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 
> Datum: 08.03.18 13:32 (GMT+01:00)
> An: dev@groovy.apache.org
> 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
>

Re: About supporting `var` of Java10+

[Aarjav Patel]

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"  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 
> Datum: 08.03.18 13:32 (GMT+01:00)
> An: dev@groovy.apache.org
> 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
>

Re: About supporting `var` of Java10+

[mg]

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 
 Datum: 08.03.18  13:32  (GMT+01:00) An: 
dev@groovy.apache.org 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

Re: About supporting `var` of Java10+

[Paul King]

On Thu, Mar 8, 2018 at 9:53 PM, mg  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 
> Datum: 08.03.18 12:26 (GMT+01:00)
> An: dev@groovy.apache.org
> 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 
> 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
>>
>
>

Re: About supporting `var` of Java10+

[Jochen Theodorou]

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

Re: About supporting `var` of Java10+

[mg]

So you could sayvar var = new Varchar();-)
 Ursprüngliche Nachricht Von: Jesper Steen Møller 
 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  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+

[mg]

Hi Paul,
I would be interested to hear if you see some advantages of going down 
the#define var defroute - apart from the obvious, that it is the 
easiest/fastest to implement ?
Cheers,mg
 Ursprüngliche Nachricht Von: Paul King  
Datum: 08.03.18  12:26  (GMT+01:00) An: dev@groovy.apache.org 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  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

Re: About supporting `var` of Java10+

[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()
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 
 Datum: 08.03.18  10:57  (GMT+01:00) An: 
dev@groovy.apache.org 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

Re: About supporting `var` of Java10+

[Paul King]

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  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
>

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

Re: About supporting `var` of Java10+

[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.
 Ursprüngliche Nachricht Von: Jochen Theodorou 
 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+

[Daniel Sun]

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+

[Jesper Steen Møller]

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+

[Daniel Sun]

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+

[Daniel Sun]

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+

[Jesper Steen Møller]

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  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+

[Jochen Theodorou]

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+

[Daniel Sun]

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+

[MG]

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