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
