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.
(2) dynamic categories via "use". Works for dynamic Groovy, does not
work for static Groovy, but does not require the manifest file.
(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.
one important note here is that dynamic categories and extension methods
do not only influence a single file. In dynamic Groovy a normal category
influences the whole call stack originating from the use-block. So if
you replace List.foo() and you call a library that uses List.foo(), then
the library will also be influenced by that. Static Categories are in my
definition limited to the block you apply them to and cannot have that
kind of influence. Which means they are quite a different beast than
normal categories and they do not exist in Groovy right now.
So basically we have to develop this as new feature. That means to
define to what it is applied, if it should work dynamic and static
(normally we want that case), think about the syntax and all the
implications - and then actually implement it. You are very welcome to
make suggestions
bye Jochen
On 10/12/26 15:32, Milles, Eric (TR Technology) via dev wrote:
I think this JIRA issue discusses some of the options and links to some
older, similar requests. https://issues.apache.org/jira/browse/
GROOVY-11143 <https://issues.apache.org/jira/browse/GROOVY-11143>
I don't think it has gained much traction since I first submitted it.
------------------------------------------------------------------------
*From:* Christopher Smith <[email protected]>
*Sent:* Friday, October 9, 2026 9:01 AM
*To:* [email protected] <[email protected]>
*Subject:* Static import for extension methods?
I use extension methods fairly heavily, up until now for creating
tooling and application-specific DSLs, and now with LLM tooling I find
the semantic compression helps improve the results. However, the
restriction that extension methods have
I use extension methods fairly heavily, up until now for creating
tooling and application-specific DSLs, and now with LLM tooling I find
the semantic compression helps improve the results. However, the
restriction that extension methods have to be compiled beforehand is a
real friction point, making it impossible to write certain kinds of
business DSLs that would be useful.
Kotlin resolves extension methods by statically importing the method and
then treating that as on the search path. How difficult would it be for
Groovy to support this mechanism also, so that methods in the same
compilation unit (or, I suppose, third-party libraries without a
manifest) could be used?
