Re: Groovy 2.4.14 on JDK8 and JDK9

[Paul King]

Sorry for being a bit late in replying. I tried Mr Haki's examples here and
had no problems (I was using Oracle JDKs 9.0.4 and 1.8.0_161 and a recent
OpenJDK 10):
http://mrhaki.blogspot.com.au/2009/12/groovy-goodness-getting-groovy-with-dom.html

Can you elaborate?

Cheers, Paul.


On Thu, Mar 8, 2018 at 3:15 AM, Russel Winder  wrote:

> Would I be right thinking that
>
> groovy.xml.DOMBuilder.parse(reader).documentElement.toString
>
> running using 2.4.14 behaves weirdly on JDK9 compared to JDK8?
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>

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 > 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 
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: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

[MG]

Hi Remi,

I have used Groovy exclusively for the last years, so not really used to 
Java lambdas, but why can't you use something along the line of:


int result = switch (s) {
    case "Foo" -> 1;
    case "Bar" -> 2;
    case default -> (System.out.println("Neither Foo nor Bar, 
hmmm...");  3; )

}

or

int result = switch (s) {
    case "Foo" -> 1;
    case "Bar" -> 2;
    case PATTERN_ANY -> { System.out.println("Neither Foo nor Bar, 
hmmm...");  3; }

}

etc ?

I am in the "never liked break camp", so I also would not want to see 
its use elevated... ;-)

Cheers,
mg


On 08.03.2018 20:52, Remi Forax wrote:



int result = switch (s) {
 case "Foo" -> 1;
 case "Bar" -> 2;
 default:
 System.out.println("Neither Foo nor Bar, hmmm...");
 break 3;
}

is straight from the JEP 325 page. And that was actually my point, this
overlap, but redefinition of break.

yes, you can not use the normal break/containue inside an expression,
so break foo; in an expression switch has only one meaning.


break is what makes the switch-case ugly for most people in the first place. 
Giving that special treatment like this looks off to me.

using break here is ugly, i agree with you but we (the amber EG) are not able 
to find a better solution,
if you know a better way to handle local return of a value in the case of a 
switch, please help us.

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: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

[Remi Forax]

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Jeudi 8 Mars 2018 19:51:57
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

> On 08.03.2018 17:34, Remi Forax wrote:
> [...]
 int accumulator = 0
 LOOP: for (T element : someList) {
accumulator += switch (element.type) {
  case PLUS_ONE -> +1;
  case MINUS_ONE -> -1;
  case ERROR:
break LOOP;
  case default -> 0
}
 }
>>>
>>> with the idea that element.type is an enum... But my problem is with
>>> break LOOP. Is LOOP the label LOOP, or is it a constant/variable?
>> 
>> this will not compile, because you can not use return or break/continue 
>> inside
>> an expression switch.
> 
> you mean I cannot use the normal break/continue inside an expression
> switch, because this example
> 
>> int result = switch (s) {
>> case "Foo" -> 1;
>> case "Bar" -> 2;
>> default:
>> System.out.println("Neither Foo nor Bar, hmmm...");
>> break 3;
>> }
> 
> is straight from the JEP 325 page. And that was actually my point, this
> overlap, but redefinition of break. 

yes, you can not use the normal break/containue inside an expression,
so break foo; in an expression switch has only one meaning. 

> break is what makes the switch-case ugly for most people in the first place. 
> Giving that special treatment like this looks off to me.

using break here is ugly, i agree with you but we (the amber EG) are not able 
to find a better solution,
if you know a better way to handle local return of a value in the case of a 
switch, please help us.

> 
>>> If they need the break only to break out of the switch, then why not
>>> capitalize on lambdas ?
>> 
>> it was the first idea :)
>> but lambda can capture effectively final local variable, when a case in an
>> expression switch acts more like a routine so you can access any variables 
>> with
>> no restriction. So re-using the same syntax for two different semantics is 
>> not
>> a good idea.
> 
> A problem you would not have in Groovy, because we don´t do the
> capturing like Java.

It's not like in java but you use a box so the perf model is still not the same 
between a captured variable and a plain old variable in Groovy. 

> 
>> The idea is that the expression switch should be used when it's a simple 
>> switch
>> and the C switch with all it's subtle behaviors if the control flow is more
>> complex,
>> exactly like you use for(:) if it's a simple loop and for(;;) if it's a more
>> complex one.
> 
> maybe, but I still think it does not make so much sense on its own. With
> a step-by-step approach of getting features in I can understand this,
> but then it means to decide to use this here, before deciding the
> details of pattern matching... and that sounds wrong.

no, the Java part of the pattern matching is mostly decided (there is still 
corner cases like how re-starting when a guard fails).
The pattern matching is delayed more because
1/ the VM support is not there, part will be in the jdk 11, but how to specify 
a sealed interface to avoid to have to specify a default when you have cover 
all the cases is still open.
2/ the support of de-constructor (extractor) to keep encapsulation without 
allocation in the middle of the pattern matching requires:
   2a/ value types, good progress have been made on the valhalla side, a 
release of value types without changing generics (which is a major PITA) may be 
a temporary solution.
   2b/ another temporary solution is to make pattern matching only working on 
records (data classes).
   
The only part of the pattern matching which is ugly IMO is how to specify a 
"local return" of a value in a case with several instructions. 

Now, releasing an expression switch first has several advantages:
- allow to align the old switch with the pattern matching switch by modernizing 
the behavior of the old switch with respect to null.
- it fixes several bugs of the current switch implementation:
  - having to recompile the switch when you change the enum
  - the switch on string being slow when the number of cases is small
  - reduce the switch footprint in term of bytecodes
- and obviously allow to use a switch that "returns" an expression. 

> 
> bye Jochen

regards,
Rémi

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: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

[Jochen Theodorou]

On 08.03.2018 17:34, Remi Forax wrote:
[...]

int accumulator = 0
LOOP: for (T element : someList) {
   accumulator += switch (element.type) {
 case PLUS_ONE -> +1;
 case MINUS_ONE -> -1;
 case ERROR:
   break LOOP;
 case default -> 0
   }
}


with the idea that element.type is an enum... But my problem is with
break LOOP. Is LOOP the label LOOP, or is it a constant/variable?


this will not compile, because you can not use return or break/continue inside 
an expression switch.


you mean I cannot use the normal break/continue inside an expression 
switch, because this example



int result = switch (s) {
case "Foo" -> 1;
case "Bar" -> 2;
default:
System.out.println("Neither Foo nor Bar, hmmm...");
break 3;
}


is straight from the JEP 325 page. And that was actually my point, this 
overlap, but redefinition of break. break is what makes the switch-case 
ugly for most people in the first place. Giving that special treatment 
like this looks off to me.



If they need the break only to break out of the switch, then why not
capitalize on lambdas ?


it was the first idea :)
but lambda can capture effectively final local variable, when a case in an 
expression switch acts more like a routine so you can access any variables with 
no restriction. So re-using the same syntax for two different semantics is not 
a good idea.


A problem you would not have in Groovy, because we don´t do the 
capturing like Java.



The idea is that the expression switch should be used when it's a simple switch 
and the C switch with all it's subtle behaviors if the control flow is more 
complex,
exactly like you use for(:) if it's a simple loop and for(;;) if it's a more 
complex one.


maybe, but I still think it does not make so much sense on its own. With 
a step-by-step approach of getting features in I can understand this, 
but then it means to decide to use this here, before deciding the 
details of pattern matching... and that sounds wrong


bye Jochen

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

[Remi Forax]

Hi Jochen,

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Vendredi 2 Mars 2018 00:57:16
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

> On 01.03.2018 16:39, Jesper Steen Møller wrote:
> [...]
>> |int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case
>> TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; };|
>> 
>> with
>> 
>> |case LABEL -> expression;|
>> 
>> essentially sugar for
>> 
>> |case LABEL: break expression;|
> 
> to make this straight.
> 
>> int result = switch (s) {
>> case "Foo":
>> break 1;
>> case "Bar":
>> break 2;
>> default:
>> System.out.println("Neither Foo nor Bar, hmmm...");
>> break 3;
>> }
> 
> is the long form of
> 
>> int result = switch (s) {
>> case "Foo" ->  1;
>> case "Bar" ->  2;
>> default:
>> System.out.println("Neither Foo nor Bar, hmmm...");
>> break 3;
>> }
> 
> The default here has no shorter version, because they are using a
> statement and need to return something in the expression. I understood
> the proposal, that both forms are valid and can be mixed.
> 
> There is a few things I dislike...and most of all it is the break
> command here.
> 
>> int accumulator = 0
>> LOOP: for (T element : someList) {
>>   accumulator += switch (element.type) {
>> case PLUS_ONE -> +1;
>> case MINUS_ONE -> -1;
>> case ERROR:
>>   break LOOP;
>> case default -> 0
>>   }
>> }
> 
> with the idea that element.type is an enum... But my problem is with
> break LOOP. Is LOOP the label LOOP, or is it a constant/variable?

this will not compile, because you can not use return or break/continue inside 
an expression switch.

> 
> If they need the break only to break out of the switch, then why not
> capitalize on lambdas ?

it was the first idea :)
but lambda can capture effectively final local variable, when a case in an 
expression switch acts more like a routine so you can access any variables with 
no restriction. So re-using the same syntax for two different semantics is not 
a good idea.

The idea is that the expression switch should be used when it's a simple switch 
and the C switch with all it's subtle behaviors if the control flow is more 
complex, 
exactly like you use for(:) if it's a simple loop and for(;;) if it's a more 
complex one.  

[...]

> 
> bye Jochen

cheers,
Rémi

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: Upcoming RC release for 2.5.0

[Paolo Di Tommaso]

Hi,

The nextflow joint build is still using 2.5.0-beta-3. I think it should use
the 2.5.0-SNAPSHOT, right?


Cheers,
Paolo


On Tue, Mar 6, 2018 at 9:12 PM, Paolo Di Tommaso 
wrote:

> I've double checked this and the compilation fails also locally using
> `2.5.0-SNAPSHOT`.
>
> I've managed to compile successfully using `2.5.0-beta-3` instead.
>
>
> Cheers,
> Paolo
>
>
> On Tue, Mar 6, 2018 at 2:29 PM, Paul King  wrote:
>
>> I temporarily set CI_GROOVY_VERSION for that joint build to 2.5.0-beta-3
>> but it seems to have been set to 2.4.13 regardless. Do you get the same
>> errors locally as we are seeing on the CI server?
>>
>>
>> On Tue, Mar 6, 2018 at 10:51 PM, Paolo Di Tommaso <
>> paolo.ditomm...@gmail.com> wrote:
>>
>>> The nextflow joint build is failing badly with the current snapshot :
>>>
>>> http://ci.groovy-lang.org/viewLog.html?buildId=47703&tab=bui
>>> ldResultsDiv&buildTypeId=JointBuilds_Nextflow_Groovy25xJointBuild#
>>>
>>> It seems it's unable static compiled classes are unable to resolve
>>> extension methods such the ones defined in this class
>>> 
>>> .
>>>
>>>
>>> p
>>>
>>> On Tue, Mar 6, 2018 at 12:41 PM, Paul King  wrote:
>>>

 I am hoping to do the first RC release of 2.5.0 late this week or next
 week. The plan being for a release in time for or during Greach. I still
 have a bunch of bugs on my list to be fixed before then, so I can't narrow
 it down more than that at this stage. Please work on any changes you want
 in for the release and any testing is greatly appreciated.

 Cheers, Paul.


>>>
>>
>

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: GPars and versions of Groovy

[Kerridge, Jon]

Hi,

It depends which bit of GPars you are using.  if you are using the CSP bit, 
sometimes known as JCSP, then this works on most JDK's back to 1.5 (I think).  
I have recompiled the code as each JDK came ut to the latest version and never 
had to chnage the underlying Java coding.  I have yet to try JDK9.  But it is 
on my todo list in the near future.


I will be making the JCSP more easily availabale with an Apache 2 licence very 
shortly.


Jon


Professor Jon Kerridge
School of Computing
Edinburgh Napier University
Merchiston Campus
Edinburgh EH10 5DT

0131 455 2777
j.kerri...@napier.ac.uk
http://www.soc.napier.ac.uk/~cs10/


From: Jim Northrop 
Sent: 06 March 2018 19:15:00
To: dev@groovy.apache.org
Subject: Re: GPars and versions of Groovy


Thanks to you for this -

Does this mean that GPars will no longer work on JDK1.7 ? What is the minimum 
jdk that we require for GPars, please ?
Thx
Jim

> On 6 Mar 2018, at 18:04, Russel Winder  wrote:
>
> On Tue, 2018-03-06 at 16:43 +, Kerridge, Jon wrote:
>> Hi,
>
> Hi Jon,
>
>> I am having the same problems with the JCSP and GroovyJCSP libraries
>> as well!
>
> It has been a very long while since I created the JCSP-1.1-rc5 artefact
> and put it into Maven Central. I can't remember which Java I used to
> build it. I am not sure I still have the Git repository with all the
> changes I needed to create the artefact.
>
>> Currently I have compilations for 2.4.14 and 2.5.x
>
> For Gant (a now useless project except for GINT) I have a Gradle build
> that builds for whichever Groovy versions I choose. Currently I assume:
>
> 2.4: 2.4.14
> 2.5: 2.5.0-beta-3
> 2.6: 2.6.0-alpha-3
> 3.0: 3.0.0-alpha-1
>
> except it doesn't build just now as I haven't upgraded the build to
> Gradle 4.6. I'll fix this. The core idea is to set Gradle to build
> multiple projects but all using the same source just with different
> dependencies. Naming is the big issue. I have gone with:
>
> gant_groovy2.4
> gant_groovy2.5
> gant_groovy2.6
> gant_groovy3.0
>
>> I am then coping with the various versions of Java as well J8, 9 10
>> and 11 before the end of this year!
>
> I am assuming a JDK8 target even though I am using JDK9. I have not
> done this as yet, but I am guessing that my one-dimensional structure
> can be extended to two dimensions by changing the path to the JDK
> version. This I think would be an excellent extension of the build
> matrix.
>
> If we need to do for GPars what I did for Gant, it would be a good
> opportunity to revise that whole build, indeed start from scratch. The
> Gant build has the added complexity of being able to build against a
> locally installed Groovy (built from Groovy master/HEAD usually).
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk


This message and its attachment(s) are intended for the addressee(s) only and 
should not be read, copied, disclosed, forwarded or relied upon by any person 
other than the intended addressee(s) without the permission of the sender. If 
you are not the intended addressee you must not take any action based on this 
message and its attachment(s) nor must you copy or show them to anyone. Please 
respond to the sender and ensure that this message and its attachment(s) are 
deleted.

It is your responsibility to ensure that this message and its attachment(s) are 
scanned for viruses or other defects. Edinburgh Napier University does not 
accept liability for any loss or damage which may result from this message or 
its attachment(s), or for errors or omissions arising after it was sent. Email 
is not a secure medium. Emails entering Edinburgh Napier University's system 
are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration 
number SC018373

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