groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <>
Subject [jira] [Commented] (GROOVY-8451) Non-Map-Based Named Parameter Support
Date Thu, 18 Jan 2018 02:01:00 GMT


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

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:
>             Project: Groovy
>          Issue Type: Improvement
>            Reporter: mgroovy
>            Priority: Major
>              Labels: named-parameters
> * Groovy should support named parameters as available in many other languages:
> * The suggested syntax and semantics are the ones used by the Kotlin programming language
> 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

View raw message