Jochen Theodorou created GROOVY-12317:
-----------------------------------------
Summary: Composable dispatch for indy
Key: GROOVY-12317
URL: https://issues.apache.org/jira/browse/GROOVY-12317
Project: Groovy
Issue Type: Improvement
Reporter: Jochen Theodorou
Right now Groovy gains more and more helper methods that are essentially a
semantic dispatcher with a dynamic method invocation as result. The problem is
those final calls are not cached.
Dynamic Call (indy + gurads + switchpoints + caching) --> Helper Method -->
Dynamic Call (reselect every time + no caching)
clear candidates are
ResourceGroovyMethods#notFiltered(File, Object, Object, Object, Object, Object)
ParallelCollectionExtensions#grepParallel(Collection, Object)
FormatHelper#tryGroovyToString(Object)
DefaultTypeTransformation#castToBooleanFallback(Object)
InvokerHelper#unaryMinus(Object)
InvokerHelper#unaryPlus(Object)
ObjectUtil#cloneObject(Object)
GString#invokeMethod(String, Object)
possible further candidates are
StringGroovyMethods#plus(CharSequence, Object)
StringGroovyMethods#minus(CharSequence, Object)
StringGroovyMethods#plus(Number, String)
StringGroovyMethods#asType(String, Class)
StringGroovyMethods#asType(GString, Class)
ArrayGroovyMethods#asType(Object[], Class)
ResourceGroovyMethods#asType(File, Class)
The method IndyCompoundAssign#resolve(CacheableCallSite, Class<?>, String,
Object[]) could give inspiration here, but the intention of the issue is a more
general mechanism that works like this:
indy selects method -> method returns continuation object -> indy continues
with the object -> indy binds result -> cached calls go through this without
asking the method again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
