[
https://issues.apache.org/jira/browse/GROOVY-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-4682:
--------------------------------
Summary: ExpandoMetaClass does not offer a consistent way to retrieve and
invoke overloaded methods (was: CLONE -ExpandoMetaClass does not offer a
consistent way to retrieve and invoke overloaded methods)
> ExpandoMetaClass does not offer a consistent way to retrieve and invoke
> overloaded methods
> ------------------------------------------------------------------------------------------
>
> Key: GROOVY-4682
> URL: https://issues.apache.org/jira/browse/GROOVY-4682
> Project: Groovy
> Issue Type: Sub-task
> Components: groovy-runtime
> Affects Versions: 1.1-rc-2
> Reporter: Marc Palmer
> Priority: Major
>
> As discussed with Graeme, take a Grails plugin for example that might supply
> a proxy "render" method for controllers, that checks for certain parameters
> and if present does something, else defers to the pre-existing render()
> method. There are several default render(...) variants overloaded, but this
> plugin replaces only a specific one:
> {code}
> def oldRender = controllerClass.metaClass.render
> controllerClass.metaClass.render = { Map m, Closure c ->
> if (!something) oldRender(m, c)
> }
> {code}
> This may work sometimes if the render method retrieved from the EMC is the
> one that takes Map, Closure. Sometimes it may not be though, and then you get
> method invocation errors when it tries to pass in the Map and Closure.
> Currently the workaround is to use metaClass.getMetaMethod( name, argTypes)
> but this gives you a different invocation paradigm - i.e. you must call
> invoke() on the MetaMethod.
> A couple of features then offer themselves as part or whole solutions:
> # Make MetaMethod support call()/doCall() as well as invoke()
> # Make EMC's methodMissing return a new MultiMetaMethodProxy object that,
> when call() is invoked, automatically determines which overloaded method to
> invoke. This could be dangerous, needs further assessment. This is the most
> elegant approach in my opinion, but I don't believe anywhere else in groovy
> treats all overloaded forms of a method as a "single" method and as such the
> terminology may not work. The concept is great, but maybe Groovy needs a new
> term for this, such as "Message" as in other OO languages. i.e. a MetaMessage
> is some invokation you can perform on an object using MetaMessage.call(args)
> but the exact method that will be called is dependent on the args, i.e. it
> knows about all the possible MetaMethods.
> # Add a new findMethod(name, argTypes) that returns a method reference
> instead of MetaMethod.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
