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

Jochen Theodorou commented on GROOVY-11161:
-------------------------------------------

I changed to static compilation because non-static Groovy does not care about 
extension methods until runtime. As for static compilation... there are 
actually type checking extensions. That could be used if the list of methods is 
known. 

The other way would be of course that kind of annotation and then the type 
checker (or a type checking extension) would have to search for these nodes and 
use them... ah I think it is not fully the same if I think of overloads. there 
might be already a fitting method, just an extension method would be maybe more 
fitting. then methodMissing would not be done in the TypeCheckingExtension. 
That means this would have to go even deeper. ..

As funny as it sounds it would probably the most easy to first compile without 
static compilation and then again with, while using the precompiled extension 
methods. 

So far I found nothing of this very attractive.

> Support extension methods inside the same compilation unit
> ----------------------------------------------------------
>
>                 Key: GROOVY-11161
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11161
>             Project: Groovy
>          Issue Type: Wish
>          Components: Static compilation, Static Type Checker
>    Affects Versions: 4.0.14
>            Reporter: Christopher Smith
>            Priority: Major
>
> Currently, the Groovy compiler supports extension methods only if they are 
> previously compiled and provided to the current compilation run on the 
> classpath. I have several projects where using extension methods to make 
> project-specific micro-DSLs would substantially improve 
> readability/maintainability, but because the extension methods need to refer 
> to business objects, I would have to slice up the project into a pile of 
> micro-projects.
> It would be very useful to be able to have a "bootstrap" mechanism to declare 
> extension methods within the same project they're applied to, in the same way 
> that annotations can be declared inside the same project. Either having an 
> annotation {{@ProvidesExtensionMethods}} or providing a {{META-INF}} file 
> (maybe being able to employ the usual mechanism for "forward extension 
> declarations"?) would accomplish what I think I'm looking for.



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

Reply via email to