[ https://issues.apache.org/jira/browse/GROOVY-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962897#comment-15962897 ]
Daniil Ovchinnikov edited comment on GROOVY-7956 at 4/10/17 2:00 PM: --------------------------------------------------------------------- Another option: {code} def foo(a, @Named b, c, @Named d) { println "$a $b $c $d" // note referring to named parameters as a regular ones } {code} This may be compiled to a regular method with a Map as a first parameter: {code} def foo(Map _it, a, c) { println "$a $_it.b $c $_it.d" } {code} The parameters then may have types and/or default values: {code} def foo(int a, @Named String b = "hello there", c, @Named d) { println "$a $b $c $d" } //compiled def foo(Map _it, int a, c) { _it.putAll(b: "hello there) // default parameters injected here println "$a ${(String)_it.b} $c $_it.d" // cast to string } {code} There is still need to store some metadata in the compiled code, for which this annotation will work GROOVY-7632. This may be implemented as an AST transformation or as a special language feature. Since each transformation slows the IDE, I'd go with new modifier, e.g. {{named}}. {code} def foo(int a, named String b = "hello there", c, named d) { println "$a $b $c $d" } {code} This for sure will break someone's sources, but it's a step to cleaner language. was (Author: daniilo): Another option: {code} def foo(a, @Named b, c, @Named d) { println "$a $b $c $d" // note referring to named parameters as a regular ones } {code} This may be compiled to a regular method with a Map as a first parameter: {code} def foo(Map _it, a, c) { println "$a $_it.b $c $_it.d" } {code} The parameters then may have types and/or default values: {code} def foo(int a, @Named String b = "hello there", c, @Named d) { println "$a $b $c $d" } //compiled def foo(Map _it, int a, c) { _it.putAll(b: "hello there) // default parameters injected here println "$a ${(String)_it.b} $c $_it.d" // cast to string } {code} There is still need to store some metadata in the compiled code, for which this annotation will work GROOVY-7632. This may be implemented as an AST transformation or as a special language feature. Since each transformation slows the IDE, I'd go with new modifier, e.g. {{named}}. {code} def foo(int a, named String b = "hello there", c, named d) { println "$a $b $c $d" } {code} This for sure will break someone's sources, but it's a step for cleaner language. > Allow @DelegatesTo on named arguments > ------------------------------------- > > Key: GROOVY-7956 > URL: https://issues.apache.org/jira/browse/GROOVY-7956 > Project: Groovy > Issue Type: New Feature > Components: GEP > Reporter: Graeme Rocher > > In order to aid static compilation for builders we have {{@DelegatesTo}} > which allows statically compiled code to know what the delegate of a closure > is. > This proposal is to allow {{@DelegatesTo}} on {{Map}} types such that IDEs > and the static compiler can resolve the target type the named arguments are > to be used on. > For example: > {code} > class Farm { > void animal(@DelegatesTo(Animal) Map arguments, > @DelegatesTo(AnimalBuilder) Closure callable) { > def animal = new Animal(arguments) > // handle closure > } > } > class Animal { String name } > {code} > The following code would then fail to compile : > {code} > def farm = new Farm() > // compilation failure, no name property on Animal > farm.animal(nam: "Dog") { > } > {code} > It would then be down to IDEs to also provide support for code completion etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)