Re: [Poll] About supporting Java-like array
I suggested CodeNarc first partly because it would be a little bit of work
to add warnings - the Groovy compiler doesn't really have any at present.
Also, Groovy has tried to not be too opinionated. If you leave those
semicolons in, Groovy won't complain. Of course removing the semicolons is
its own reward! :-)
Cheers, Paul.
On Mon, Apr 30, 2018 at 10:30 PM, mg wrote:
> Yes, but what about all the (hopefully many) people new to Groovy, who
> don't use CodeNarc ? How do you educate them about what is idiomatic Groovy
> ?
> Especially in cases like this, where a completely equivalent Groovy
> alternative exists...
>
> I imagine something along the line:
>
> Warning: Using {...} Java style array literals is not idiomatic Groovy. To
> avoid confusion with Groovy closures, it is recommended to use the
> performance-identical Groovy [...] list literal syntax instead.
>
> I think we should decide if that is something we want to do in general, or
> not. My argument for it is, to avoid Groovy becoming a
> Babylonian-syntax-language like e.g. Ruby...
>
> Cheers,
> mg
>
>
>
>
>
> Ursprüngliche Nachricht
> Von: Paul King
> Datum: 30.04.18 01:51 (GMT+01:00)
> An: users@groovy.apache.org
> Betreff: Re: [Poll] About supporting Java-like array
>
>
>
> On Mon, Apr 30, 2018 at 9:10 AM, mg wrote:
>
>> I would propose the Groovy compiler issue a warning to change the array
>> initialization from Java- to Groovy-style then...
>>
>
> A codenarc rule would be a great first option.
>
>
>> Cheers,
>> mg
>>
>>
>>
>> Ursprüngliche Nachricht
>> Von: Paul King
>> Datum: 30.04.18 00:29 (GMT+01:00)
>> An: users@groovy.apache.org
>> Betreff: Re: [Poll] About supporting Java-like array
>>
>> The preferred Groovy syntax would probably still remain:
>>
>> int[] fibs = [1, 1, 2, 3, 5, 8]
>>
>> Cheers, Paul.
>>
>> On Mon, Apr 30, 2018 at 7:17 AM, MG wrote:
>>
>>> After thinking about this some more for the last weeks
>>> +1 with asterisk
>>> from my side:
>>>
>>> 1) I am always for being as Java compatible as possible (though I see
>>> that this might not be feasible in all cases in the future, due to Java
>>> changing at a much faster pace and with more syntax changes now than
>>> before; example: Java considered naming the new "var" keword "def", which
>>> is similar to but not the same as Java-var in Groovy...)
>>>
>>> 2) I feel { { } } being interpreted as an array containing an empty
>>> closure is confusing, i.e. not least surprise. I would rather not see it
>>> cut it so close with regards to what the Parrot parser can handle
>>> syntax-wise. What do others think ?
>>>
>>> 3) After introducing this syntax extension, what will be considered the
>>> "Groovy way" of initializing an array in the future ? Is it still
>>> final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]
>>> or
>>> final int[] a = { 1, 1, 2, 3, 5, 8 }
>>> ?
>>> In the 2nd case I would be worried that the core Groovy syntax becomes
>>> all over the place over time, same as with the new Java lambda syntax
>>> (though less pronounced, since using/initializing arrays is typically rare).
>>>
>>> 4) I am not too worried about the breaking edge cases, because I feel
>>> they are quite rare in practice, the compiler catches them, and they are
>>> easy to fix.
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>>
>>>
>>> On 29.04.2018 15:29, Paul King wrote:
>>>
>>> +1
>>>
>>> For completeness, I added some more details about the breaking changes
>>> and workarounds into the issue - included below for easy reading.
>>>
>>> Cheers, Paul.
>>>
>>> =
>>>
>>> Groovy currently "promotes" a singleton instance of an object into an
>>> array for assignments, e.g.:
>>>
>>> Integer[] nums = 42
>>> assert nums instanceof Integer[]
>>> assert nums.size() == 1
>>> assert nums[0] instanceof Integer
>>>
>>> This aligns with how Groovy behaves if you try to call `.each{}` on a
>>> non-aggregate. It treats it like a singleton collection and "iterates" over
>>> the one item.
>>>
>>> The existing behavior also currently works for singleton Closures:
>>>
>>> Closure[] fns0 = { }
>>> assert fns0 instanceof Closure[]
>>> assert fns0.size() == 1
>>> assert fns0[0] instanceof Closure
>>>
>>> To add support for Java array notation, we will need to partially
>>> disable this behavior. The proposed change involves smart parsing, e.g. it
>>> will distinguish cases which must be an array and cases which must be a
>>> closure but there are some degenerate edge cases which will become breaking
>>> changes.
>>>
>>> The case with the empty closure above will no longer work, instead you
>>> will get this behavior, i.e. an empty array is given precedence over an
>>> empty closure:
>>>
>>> Closure[] fns1 = { }
>>> assert fns1 instanceof Closure[]
>>> assert fns1.size() == 0
>>>
>>> To get the old behavior back you have a couple of options. Firstly, you
>>> can provide the explicit closure argument delimiter:
>>>
>>> Closure[] fns2 = { -> } // can't be an array
>>> assert fns2 instan
Re: [Poll] About supporting Java-like array
Yes, but what about all the (hopefully many) people new to Groovy, who don't
use CodeNarc ? How do you educate them about what is idiomatic Groovy
?Especially in cases like this, where a completely equivalent Groovy
alternative exists...
I imagine something along the line:
Warning: Using {...} Java style array literals is not idiomatic Groovy. To
avoid confusion with Groovy closures, it is recommended to use the
performance-identical Groovy [...] list literal syntax instead.
I think we should decide if that is something we want to do in general, or not.
My argument for it is, to avoid Groovy becoming a Babylonian-syntax-language
like e.g. Ruby...
Cheers,mg
Ursprüngliche Nachricht Von: Paul King
Datum: 30.04.18 01:51 (GMT+01:00) An: users@groovy.apache.org Betreff: Re:
[Poll] About supporting Java-like array
On Mon, Apr 30, 2018 at 9:10 AM, mg wrote:
I would propose the Groovy compiler issue a warning to change the array
initialization from Java- to Groovy-style then...
A codenarc rule would be a great first option. Cheers,mg
Ursprüngliche Nachricht Von: Paul King
Datum: 30.04.18 00:29 (GMT+01:00) An: users@groovy.apache.org Betreff: Re:
[Poll] About supporting Java-like array
The preferred Groovy syntax would probably still remain:
int[] fibs = [1, 1, 2, 3, 5, 8]
Cheers, Paul.
On Mon, Apr 30, 2018 at 7:17 AM, MG wrote:
After thinking about this some more for the last weeks
+1 with asterisk
from my side:
1) I am always for being as Java compatible as possible (though I
see that this might not be feasible in all cases in the future, due
to Java changing at a much faster pace and with more syntax changes
now than before; example: Java considered naming the new "var"
keword "def", which is similar to but not the same as Java-var in
Groovy...)
2) I feel { { } } being interpreted as an array containing an empty
closure is confusing, i.e. not least surprise. I would rather not
see it cut it so close with regards to what the Parrot parser can
handle syntax-wise. What do others think ?
3) After introducing this syntax extension, what will be considered
the "Groovy way" of initializing an array in the future ? Is it
still
final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]
or
final int[] a = { 1, 1, 2, 3, 5, 8 }
?
In the 2nd case I would be worried that the core Groovy syntax
becomes all over the place over time, same as with the new Java
lambda syntax (though less pronounced, since using/initializing
arrays is typically rare).
4) I am not too worried about the breaking edge cases, because I
feel they are quite rare in practice, the compiler catches them, and
they are easy to fix.
Cheers,
mg
On 29.04.2018 15:29, Paul King wrote:
+1
For completeness, I added some more details about the
breaking changes and workarounds into the issue - included
below for easy reading.
Cheers, Paul.
=
Groovy currently "promotes" a singleton instance of an
object into an array for assignments, e.g.:
Integer[] nums = 42
assert nums instanceof Integer[]
assert nums.size() == 1
assert nums[0] instanceof Integer
This aligns with how Groovy behaves if you try to call
`.each{}` on a non-aggregate. It treats it like a singleton
collection and "iterates" over the one item.
The existing behavior also currently works for singleton
Closures:
Closure[] fns0 = { }
assert fns0 instanceof Closure[]
assert fns0.size() == 1
assert fns0[0] instanceof Closure
To add support for Java array notation, we will need to
partially disable this behavior. The proposed change
involves smart parsing, e.g. it will distinguish cases which
must be an array and cases which must be a closure but there
are some degenerate edge cases which will become breaking
changes.
The case with the empty closure above will no longer
work, instead you will get this behavior, i.e. an empty
array is given precedence over an empty closure:
Closure[] fns1 = { }
assert fns1 instanceof Closure[]
assert fns1.size() == 0
To get the old behavior back you have a couple of
options. Firstly, you can provide the explicit closure
argument delimiter:
C
Re: [Poll] About supporting Java-like array
Will do. What do we think about the required strictness of the RHS list literal
matching the LHS array type ? Should this be required to be more 1:1 than in
the "as" case ?E.g. shallint[][][] aaa3 = 1still be valid ?
Cheers,mg
Ursprüngliche Nachricht Von: Paul King
Datum: 30.04.18 05:18 (GMT+01:00) An: users@groovy.apache.org Betreff: Re:
[Poll] About supporting Java-like array
That sounds like a limitation we'd like to remove when using @CompileStatic.
Want to create a Jira?
Cheers, Paul.
On Mon, Apr 30, 2018 at 12:39 PM, MG wrote:
Hi Daniel,
I did a quick check and it works with dynamic Groovy, but is
rejected under static compilation:
@Test
@Ignore
void arrayFromListLiteral() {
int[] a0 = [1,2,3]
int[][] aa0 = [[1,2,3],[4,5,6]]
int[][][] aaa0 = [[[1],[2],[3]],[[4],[5],[6]]]
int[][][] aaa1 = [[1,2,3],[4,5,6]]
int[][][] aaa2 = [1,2,3,4,5,6]
int[][][] aaa3 = 1
println "a0=$a0"
println "aa0=$aa0"
println "aaa0=$aaa0"
println "aaa1=$aaa1"
println "aaa2=$aaa2"
println "aaa3=$aaa3"
assert a0 instanceof int[]
assert aa0 instanceof int[][]
assert aaa0 instanceof int[][][]
assert aaa1 instanceof int[][][]
assert aaa2 instanceof int[][][]
assert aaa3 instanceof int[][][]
}
gives:
a0=[1, 2, 3]
aa0=[[1, 2, 3], [4, 5, 6]]
aaa0=[[[1], [2], [3]], [[4], [5], [6]]]
aaa1=[[[1], [2], [3]], [[4], [5], [6]]]
aaa2=[[[1]], [[2]], [[3]], [[4]], [[5]], [[6]]]
aaa3=[[[1]]]
with @CompileStatic the compiler gives:
Error:(37, 19) Groovyc: [Static type checking] - Cannot assign value
of type java.util.List into array of type
int[][]
Error:(38, 22) Groovyc: [Static type checking] - Cannot assign value
of type java.util.List into array of type
int[][][]
Error:(39, 22) Groovyc: [Static type checking] - Cannot assign value
of type java.util.List into array of type
int[][][]
Error:(40, 22) Groovyc: [Static type checking] - Cannot assign value
of type int into array of type int[][][]
Error:(41, 22) Groovyc: [Static type checking] - Cannot assign value
of type int to variable of type int[][][]
and one has to do
int[][] aa0 = [[1,2,3],[4,5,6]] as int[][]
etc
Cheers,
mg
On 30.04.2018 02:02, Daniel Sun wrote:
Hi mg,
As far as I remember, two dimensional array like`int[][] a = [[1, 2,
3], [4, 5, 6]]` will go wrong in the Groovy style.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
