[jira] [Updated] (GROOVY-8451) Non-Map-Based Named Parameter Support

["mgroovy (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-8451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

mgroovy updated GROOVY-8451:
----------------------------
    Description: 
* 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}
* Arguments for using assignment (x=123) over map syntax (x:123) for named parameter value assignment:
## Map syntax would collide with a ctor which takes a map as its argument, if the syntax is going to be mapped to a map
## Assignment operator is better to read/clearer
## Map syntax could be confused with a map parameter
## Default parameters are also given using assignment operator, so why use a different operator when assigning parameters a value during call time ?
## Supplies clear separation from existing limited map based default parameters support

  was:
* 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}


> 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}
> * Arguments for using assignment (x=123) over map syntax (x:123) for named parameter value assignment:
> ## Map syntax would collide with a ctor which takes a map as its argument, if the syntax is going to be mapped to a map
> ## Assignment operator is better to read/clearer
> ## Map syntax could be confused with a map parameter
> ## Default parameters are also given using assignment operator, so why use a different operator when assigning parameters a value during call time ?
> ## Supplies clear separation from existing limited map based default parameters support



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)