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

Eric Milles commented on GROOVY-11489:
--------------------------------------

GROOVY-2521, GROOVY-8427, GROOVY-11143, GROOVY-11161 discuss some similar 
concerns and capabilities 

> In-project extension methods
> ----------------------------
>
>                 Key: GROOVY-11489
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11489
>             Project: Groovy
>          Issue Type: Wish
>          Components: Compiler
>    Affects Versions: 4.0.23
>            Reporter: Christopher Smith
>            Priority: Major
>
> I make thorough use of extension methods to build DSLs both for libraries and 
> for business applications, but the limitation that extension methods have to 
> exist before the compilation unit starts is a major drawback (for example, I 
> can't define extension methods on some library type that refer to 
> business-domain objects). While dabbling with Kotlin for an Android app, I 
> noticed that Kotlin manages the selection of extension methods by using 
> {{import static}} to specify the method, allowing references to extension 
> methods that reside in the compilation unit where they're consumed.
> It would be a major quality-of-life improvement to be able to define 
> extension methods in the same place where they're used. I can think of a 
> number of approaches that might work, in approximate descending order of 
> convenience:
>  # Consider the local compilation unit's META-INF entry for extension methods.
>  # Use {{import static}} or similar syntax to specifically identify extension 
> methods that should be considered.
>  # Provide an annotation applied to the class providing the extension methods 
> that would cause the compiler to make them available.
>  # Provide an annotation applied to the consuming class specifying where to 
> look.
> #3 might have some chicken-and-egg problems relating to partial compilation, 
> but the others may be less tricky.



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

Reply via email to