groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Groovy 3.0: Multiline list/map arguments
Date Fri, 06 Apr 2018 21:29:31 GMT
On 06.04.2018 21:21, MG wrote:
> My suggestion was not to consider allowing any whitespace to break 
> syntax ambiguity here, but only a newline after the opening square 
> bracket, i.e.:

whitespace in terms of the groovy grammar includes newline usually.

> // Still does not compile
> final result = foo [ "some rather long literal string argument",
>      "another long literal string argument",
>      "and so on and so forth...",
> ]
> 
> // Parsed as foo([ ... ])  (not foo-index-access)
> final result = foo [
>       "some rather long literal string argument",
>      "another long literal string argument",
>      "and so on and so forth...",
> ]

so you want

list[0]

keep as is now and

list[
   0
]

be instead list([0])?

> If the parser can do it, it would feel Groovy to me to allow it for this 
> use case (Of course it could still mean "index access", but how many 
> people would really write an index access on foo that way ?).

asking "but how many people would" is always to be answered with 
"potentially many"

> Groovy 3.0 is the place to ponder such questions, imho, because breaking 
> changes will come anyway afaiks (Java 9 modules), so you do it here, or 
> not for a long time...
> 
> Would be interested what others think, or if someone has a counter 
> example that makes it clear it is a bad idea to go down that route,

why not use

>> final result = foo (
>>      "some rather long literal string argument",
>>      "another long literal string argument",
>>      "and so on and so forth..."
>> )

instead and make foo use Object...? The real problem is a different one 
imho.

people try things and start debugging code with println. They have for 
example

return [x,y]

and change this now to

println [x,y]
return [x,y]

or log it...

Obviously they started with a list and do not want indexing at all. They 
want the method call variant you propose. But in my experience this has 
really been the only case where it plays a role. And I think to give it 
up just because of that... give up I mean because I prefer having to 
write println([x,y]) to simulate the method call, than having to 
write... println.getAt([x,y]) to simulate the index. Especially since 
the later requires people to actually now the method name used for the 
index operation, which in most cases, they will not care about really. 
And do you really want to write

println [
  x,y]

to get a method call?

bye Jochen

Mime
View raw message