On Mon, Oct 12, 2026, 12:58 Jochen Theodorou via dev <[email protected]> wrote:
> Hi Eric and Christopher, > > possible "solutions": > > (1) make a build with the extensions methods in their own compilation > unit and let the build use the created extension methods. This works > with dynamic and static Groovy, requires a build system and changes to > the extension methods require a rebuild of that > sub-project/module/source set. > This is the specific approach I am trying to escape. I want, inside a business application, to be able to define extension methods *that refer to business objects* and use them. (2) dynamic categories via "use". Works for dynamic Groovy, does not > work for static Groovy, but does not require the manifest file. > I use almost exclusively static mode. (3) new feature static categories, which I proposed as an application of > the realms concept, that barely anybody here was interested in > > (4) another new feature based on static imports, trying to implement > static categories based on "use", another concept altogether. > I'm not sure about *categories*, but the UX I had in mind was essentially identical to Kotlin's, that explicitly importing the method (via whichever syntax) would affect resolution only for that file in exactly the same manner as an import does now, only making it available for method resolution. My only goal is to work around the current limitation of "extension methods must live on the binary classpath" by adding a syntax that tells the compiler "also prepend this search path locally". (I suppose an @ExtensionMethod ASTT annotation on the method might work as long as it ran in an early phase?) Christopher Smith
