[jira] [Comment Edited] (GROOVY-9510) DelegatesTo and similar for annotation member methods

["Leonard Brünings (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17751151#comment-17751151 ] 

Leonard Brünings edited comment on GROOVY-9510 at 8/4/23 3:31 PM:
------------------------------------------------------------------

[~emilles] can you provide some example how that would look, all I know is how to do this for method calls. 
I have tried numerous times to make sense of the GDSL/DSLD, but the examples are rather limited and I couldn't find any that deal with closures for annotations.
It is not for lack of trying that we don't have those in the Spock's GDSL/DSLD definitions yet.

bq. Any change to allow @ClosureParams or @DelegatesTo in new positions would require IDE changes to support for purposes of content assist, syntax highlighting, etc.

I don't really think that is an argument against doing this, as IDEs have to support new features all the time and have done so. 
There were also GDSLs/DSLDs for features that are now described with Groovy's built-in annotations, following that logic it wouldn't have made sense to add those annotations at all.

I would also add, that I've seem more instances of annotations with closure params where this would be useful outside of Spock's code base, requiring all those users to write GDSLs/DSLDs doesn't strike me as a great solution.


was (Author: leonard84):
[~emilles] can you provide some example how that would look, all I know is how to do this for method calls. 
I have tried numerous times to make sense of the GDSL/DSLD, but the examples are rather limited and I couldn't find any that deal with closures for annotations.
It is not for lack of trying that we don't have those in the Spock's GDSL/DSLD definitions yet.

bq. Any change to allow @ClosureParams or @DelegatesTo in new positions would require IDE changes to support for purposes of content assist, syntax highlighting, etc.

I don't really think that is an argument against doing this, as IDEs have to support new features all the time and have done so. 
There were also GDSLs/DSLDs for features that are now described with Groovy's built-in annotations, following that logic it wouldn't have made sense to add those annotations at all.

> DelegatesTo and similar for annotation member methods
> -----------------------------------------------------
>
>                 Key: GROOVY-9510
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9510
>             Project: Groovy
>          Issue Type: Bug
>            Reporter: Björn Kautler
>            Priority: Major
>              Labels: annotations
>
> If you have an annotation with a closure field like for example this in Spock:
> {code:java}
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE, ElementType.METHOD})
> @ExtensionAnnotation(RequiresExtension.class)
> public @interface Requires {
>   Class<? extends Closure> value();
> }{code}
> you can use it like
> {code:java}
> @Requires({ os.windows }){code}
> But I see no way to add IDE-hints for that closure like {{@DelegatesTo(PreconditionContext.class)}} as it is restriced to parameters.
> It would be nice if you could also annotate annotation member methods (and if IDEs would then support that too).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)