[jira] [Comment Edited] (GROOVY-7232) Delegation inconsistent between methods and properties in nested closures

["Eric Milles (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153110#comment-17153110 ] 

Eric Milles edited comment on GROOVY-7232 at 7/7/20, 9:33 PM:
--------------------------------------------------------------

[~paulk] or [~blackdrag],

Could you clarify how the resolve strategies {{DELEGATE_FIRST}} and {{OWNER_FIRST}} are expected to work in terms of {{methodMissing}}?  If the strategy is {{OWNER_FIRST}} (default) I would expect the entire owner tree (including delegates for enclosing closures) to be explored out to the enclosing class before the delegate is consulted.

The test {{gls.closures.ResolveStrategyTest#testDynamicSettingOfResolveStrategy}} seems to suggest that {{methodMissing}} is not to be invoked on owner's hierarchy if delegate has the property.  And {{ClosureMetaClass}} seems to be implemented in terms of looking for existing methods on owners and delegates before getting into {{methodMissing}}.

There is no clarity on checking for existing methods vs. calling {{methodMissing}} in: https://docs.groovy-lang.org/latest/html/documentation/#_delegation_strategy_2


I have a simple solution for this ticket using the power of {{InvokerHelper#invokeMethod}} to explore owner first and then try delegate.  There is only one test that has an issue with the change.


was (Author: emilles):
[~paulk] or [~blackdrag] Could you clarify how the resolve strategies {{DELEGATE_FIRST}} and {{OWNER_FIRST}} are expected to work in terms of {{methodMissing}}?  If the strategy is {{OWNER_FIRST}} (default) I would expect the entire owner tree (including delegates for enclosing closures) to be explored out to the enclosing class before the delegate is consulted.

The test {{gls.closures.ResolveStrategyTest#testDynamicSettingOfResolveStrategy}} seems to suggest that {{methodMissing}} is not to be invoked on owner's hierarchy if delegate has the property.  And {{ClosureMetaClass}} seems to be implemented in terms of looking for existing methods on owners and delegates before getting into {{methodMissing}}.

There is no clarity on checking for existing methods vs. calling {{methodMissing}} in: https://docs.groovy-lang.org/latest/html/documentation/#_delegation_strategy_2


I have a simple solution for this ticket using the power of {{InvokerHelper#invokeMethod}} to explore owner first and then try delegate.  There is only one test that has an issue with the change.

> Delegation inconsistent between methods and properties in nested closures
> -------------------------------------------------------------------------
>
>                 Key: GROOVY-7232
>                 URL: https://issues.apache.org/jira/browse/GROOVY-7232
>             Project: Groovy
>          Issue Type: Bug
>          Components: groovy-runtime
>    Affects Versions: 2.3.2, 2.3.7, 2.4.0-rc-1
>            Reporter: Matthew Farrell
>            Assignee: Eric Milles
>            Priority: Major
>         Attachments: DelegateTest.groovy
>
>
> When a closure's resolveStrategy is set to DELEGATE_ONLY or DELEGATE_FIRST, resolution is different in nested closures between methods and properties of the delegate. For example, in the following, {{x}} resolves to {{f}}'s delegate (what I expect), but {{keySet()}} resolves to {{g}}'s delegate.
> {code}
> ​def g = {->
>     def f = {
>         {-> [x, keySet()]}()
>     }
>     f.resolveStrategy = Closure.DELEGATE_ONLY
>     f.delegate = [x: 1, f: 0]
>     f()
> }      
> g.delegate = [x: 0, g: 0]
> g()
> {code}
> ​ Result: {code}[1, ['x', 'g']]{code}
> Whereas without the nested closure
> {code}
> def g = {->
>     def f = {
>         [x, keySet()]
>     }
>     f.resolveStrategy = Closure.DELEGATE_ONLY
>     f.delegate = [x: 1, f: 0]
>     f()
> }      
> g.delegate = [x: 0, g: 0]
> g()
> {code}
> Result: {code}[1, ['x', 'f']]{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)