[
https://issues.apache.org/jira/browse/GROOVY-11489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886440#comment-17886440
]
Eric Milles edited comment on GROOVY-11489 at 10/2/24 4:47 PM:
---------------------------------------------------------------
GROOVY-2521, GROOVY-8417, GROOVY-11143, GROOVY-11161 discuss some similar
concerns and capabilities
was (Author: emilles):
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)
