[ https://issues.apache.org/jira/browse/GROOVY-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15546427#comment-15546427 ]
Jason Winnebeck commented on GROOVY-7956: ----------------------------------------- This is an awesome idea, although I'm not sure that reusing {{@DelegatesTo}} is the most clear option... But whatever the annotation would be called, this would also be a great improvement for any "options-like" API more common in the JavaScript/TypeScript world but we see it for example with Groovy http-builder: {code} x.post( path: 'update.json', body: [ status: msg, source: 'httpbuilder' ], requestContentType: URLENC ) {code} In this case it would be nice if the path, body, and requestContentType were known to the Groovy static compiler and IDEs. If there was a way to describe the structure (supporting even nested objects), it would be nice. There would be some question whether or not there should be a "prototype" type (as in the original proposal, like {{@Properties(Animal)}}) supported in addition to a "descriptive" form purely in annotations that would be supported even for dynamic mode (for example {{@Properties(\[x: Integer, y: Integer])}} for a method taking a Map of x,y values). > 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.4#6332)