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 Champions proposal feedback
Date Fri, 16 Feb 2018 00:52:46 GMT
On 14.02.2018 22:50, MG wrote:
[...]
> but these are no-brainers, e.g. the semantics of inline closures, or 
> that final variables with no explicit type are not of type Object, but 
> of the type they were assigned, or named parameters support which does 
> not try to force-map the problem to a (non type safe) map.

just wanting to comment here...

For me inline closures are not a no-brainer, not at all. just because 
their solution may look simple does not mean it was easy to develop or 
that it can be used for Groovy.

final variables with no explicit type not being of type Object is the 
case for type-checked variant and in normal Groovy it does not play any 
role (not even the modifier does play a real role in the compilation result)

for the named parameters support the map solution does only not suffice 
for the static compiler in the end... A pragmatic solution would be to 
say foo(x:1) can call foo(int) if the parameter is named x and that this 
call is taken even if there is a foo(Map) variant, plus that dynamic 
Groovy will always call the map variant. And then somebody has to 
implement this based on the java8 parameter information (which means 
java8 will be required for this feature of course). All doable, given time


bye Jochen

Mime
View raw message