[jira] [Created] (GROOVY-9532) Add real named parameters

["Dirk Heinrichs (Jira)" <ji...@apache.org>]

Dirk Heinrichs created GROOVY-9532:
--------------------------------------

             Summary: Add real named parameters
                 Key: GROOVY-9532
                 URL: https://issues.apache.org/jira/browse/GROOVY-9532
             Project: Groovy
          Issue Type: Wish
          Components: Compiler
            Reporter: Dirk Heinrichs


Maybe it's too late for 4.x, but having real named parameters instead of/in addition to the current, map-based, named parameters would be really helpful.

A full featured named parameter implementation would
 * enable type checking
 * find errors at compile time
 * eleminate the need to take care of parameter ordering in method calls
 * enhance code readability
 * be far less error prone

For example:
{code:java}
def foo(String param1, String param2 = 'val2', String param3) {} {code}
could then be invoked like
{code:java}
foo(param3: 'val3', param1: 'val1')
foo(param1: 'val1', param3: 'val3')
foo(param3: 'val3', param1: 'val1', param2: 'somehing else'){code}
while
{code:java}
foo(param2: 'val3', param1: 'val1'){code}
would lead to a compilation error because 'param3' is missing.

With map-based named parameters, this is all left to the method author and leads to massive amount of boiler plate code to do the type checking and such in the methods, or if not done, like in the documentation examples, to unexpected runtime errors, for example:
{code:java}
def foo(Map args) {
  println(args.name)
}{code}
could easily be called like
{code:java}
foo(name: 42){code}
without leading to an error although "name" is meant to be String. One has to do something like
{code:java}
def foo(Map args) {
  if (!(args.name instanceof String)) {
    throw new IllegalArgumentException('name must be of type String.')
  }
  println(args.name)
}{code}
to catch this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)