codeconsole commented on PR #15669:
URL: https://github.com/apache/grails-core/pull/15669#issuecomment-4712174754
> @codeconsole I believe I've addressed your finding in the latest commit.
Concerning the overall change, do you think we should require the registry
solution to move forward with this or is this solution "good enough" that we
can proceed with it? Obviously the registry solution is the "correct" solution,
but it's a much larger (and impactful change) since every taglib would have to
be recompiled.
Confirmed — tested the latest commit against a real
CriteriaTypeCheckingExtension (not the stub) with the catch-all registered last
and actual createCriteria{} closures in a @GrailsCompileStatic controller. The
DYNAMIC_RESOLUTION deferral resolves it: no more ambiguous-method error.
Good enough to proceed, but the registry would be ideal. The question is
whether to tackle it now in 8.x or later at another major version. This is fine
for an intermediary solution.
At runtime each tag call from a controller stays a dynamic call site (the
same methodMissing → tag-lookup →
captureTagOutput path used today in non-statically-compiled Groovy).
The registry solution would generate real methods, so the call becomes a
direct invokevirtual — measurably faster per call.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
