Hi Paul,
is this commentz still valid: "As currently designed, it works for
dynamic Groovy and/fails when using static compilation/. This is kind of
as I'd expect since we have a "dangling" method reference not associated
with a functional interface."
Applied to your example, why would Person::validate be dangling under
static compilation ? Is it "just" that at the point in time when the
Groovy compiler tries to process Person::validate, it is not yet
resolved/resolvable ? Would that also mean it would currently not work
under @TypeChecked ?
Cheers,
mg
On 20/07/2024 13:14, Paul King wrote:
Hi folks,
I created a PR here:
https://github.com/apache/groovy/pull/2097
For issue GROOVY-11432:
https://issues.apache.org/jira/browse/GROOVY-11432
It provides a fairly simple mechanism to support method
references/method pointers in annotation members. It piggybacks on the
existing closure support. Basically for an example using a closure:
@TupleConstructor(post={ assert first && last })
class Person {
final String first, last
}
You could now rewrite like this (to allow the validate method to be
used also in other contexts):
@TupleConstructor(post=Person::validate)
class Person {
final String first, last
void validate() { assert first && last }
}
It is rewritten to this:
@TupleConstructor(post={ this.withClosureMethod(Person::validate) })
class Person {
final String first, last
void validate() { assert first && last }
}
There is nothing to stop other AST transforms from re-wrapping the
call to withClosureMethod to be a direct call to some
java.util.function.Function/Supplier/Consumer. Note: I added the
DGM#withClosureMethod to provide a hook that would work for both
dynamic and static Groovy.
I believe it would work well for the scenario posed for
Timefold/Optaplanner as well as various tweaks we could make to our
existing AST transforms and for frameworks like Grails. It also works
well with the recent GROOVY-11443 enhancement for design-by-contract
scenarios where method references could now be mixed with other method
references, or ad-hoc closures to specify pre/post-conditions &
invariants.
Also, by piggybacking in this way, should Java ever support this
feature (as they discussed in [1]), the Java mechanism should not be
impacted by this mechanism
Let me know if you have any thoughts.
.
Cheers, Paul.
[1]https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056596.html
Cheers, Paul.
