[
https://issues.apache.org/jira/browse/GROOVY-8451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329882#comment-16329882
]
Paul King commented on GROOVY-8451:
-----------------------------------
There is potentially no reason not to use the existing syntax (colon vs
equals). It would potentially be a breaking change but only in rare cases I
imagine, so I would suggest this is a 3.0 feature (possibly one of the features
we don't backport to 2.6).
The behavior can be to look for an appropriate tuple method/constructor which
contains the appropriate naming information. If no such matching method is
found then look for the Map-based alternative. Currently we don't store away
the parameter name information during compilation, so we have some things to
tweak before we could enable this. We have the {{-pa/--parameters}} switch
which stores away parameter name information for jdk8+ JDKs. We don't currently
turn this on by default but we could. We could also use some kind of annotation
to track such information. We wouldn't necessarily have this information for
classes compiled with older versions of Groovy.
We value highly Java integration, so we wouldn't want to turn off the existing
Map-based approach. And we'd still want AST transformations that supported the
old style as it keeps the current integration options available. We might have
a more elaborate integration story for Java depending on the approach chosen.
> Non-Map-Based Named Parameter Support
> -------------------------------------
>
> Key: GROOVY-8451
> URL: https://issues.apache.org/jira/browse/GROOVY-8451
> Project: Groovy
> Issue Type: Improvement
> Reporter: mgroovy
> Priority: Major
> Labels: named-parameters
>
> * Groovy should support named parameters as available in many other languages:
> https://en.wikipedia.org/wiki/Named_parameter
> * The suggested syntax and semantics are the ones used by the Kotlin
> programming language
> https://kotlinlang.org/docs/reference/functions.html#named-arguments
> since
> ## using the assignment operator to define named parameter values
> *** Seems a very organic choice in the Java family of languages
> *** Differentiates the syntax clearly from the alternate/existing Groovy map
> based named parameter support
> ## The design decisions are relatively straightforward
> ## Kotlin syntax is close to Groovy (apart from some odd deviations), so what
> works there should work in Groovy
> * Features:
> ** Parameters are assigned a value prioritized in the following order:
> ### positional value
> ### named parameter value
> ### default value
> ** Parameters which do not have a default value must be given when calling
> the method
> ** All non-named parameters must come before named-parameters
> ** Named parameters can be given in any order
> * Example:
> {code}
> void foo(final x0, final x1, final x2 = defVal2, final x3 = defVal3, final x4
> = defVal4) { /* ... */ }
> // x0 = val0, x1 = val1, x2 = val2, x3 = defVal3, x4 = val4
> foo(val0, x2 = val2, x4 = val4, x1 = val1)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
