Hi Christoph,
On 10/12/26 20:06, Christopher Smith wrote:
[...]
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?)
They are defined in Kotlin like a fallback: if you have a call foo.bar()
and bar() is not defined on foo, then search for an extension with a
compatible signature. That means if the type of foo or any ancestor of
it defines bar() the extension is not used in Kotlin. That is not really
a concept we have currently in Groovy at all. We have missing-method
logic, but that is a catch-all fallback.
You could try a type checking extension like this:
https://github.com/blackdrag/snippets/blob/groovy-command-dsl/src/main/groovy/demo/ContainerDslExtension.groovy
disclaimer: This is AI generated to show the principle.
Anyway... what that code is supposed to do is to extend the static
compiler to change method call resolution (See also
https://docs.groovy-lang.org/latest/html/documentation/#type-checking-extensions).
This variant would first try to resolve a method against a given class
in extension method style and rewrite the calls to use it, if found. You
could also use methodNotFound instead of beforeMethodCall to get a
similar result to the Kotlin variant.
That would get you near what you are looking for I imagine.
bye Jochen
