I updated that old comment. It does now work with @TypeChecked/@CompileStatic. The "dangling" method comment was short for, the "with" method (in previous PR) isn't recognized as having a functional interface.
Paul. On Sun, Jul 21, 2024 at 8:35 AM MG <mg...@arscreat.com> wrote: > > 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. > >
