[jira] [Assigned] (GROOVY-6510) Problems with implicit closures inside of @Category-annotated classes

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

     [ https://issues.apache.org/jira/browse/GROOVY-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Milles reassigned GROOVY-6510:
-----------------------------------

    Assignee: Eric Milles

> Problems with implicit closures inside of @Category-annotated classes
> ---------------------------------------------------------------------
>
>                 Key: GROOVY-6510
>                 URL: https://issues.apache.org/jira/browse/GROOVY-6510
>             Project: Groovy
>          Issue Type: Bug
>            Reporter: David Hangl
>            Assignee: Eric Milles
>            Priority: Major
>         Attachments: ClosureInsideExtensionOrCategoryTest.groovy
>
>
> The behavior of implicit closures is in my opinion broken when used inside of a category.
> As you can see in the attached TestCase in a simplified example, I had the following scenario:
> - first there is an utility method (in the example the method ClosureInvoker#setDelegateAndInvokeClosure(Closure)) that gets a closure, resets the delegate object of it and calls this closure.
> - next we have an ExtendedClass which isn't really used in the example itself other than being used as "base"-class for the category/extension-methods. This is just because its own functionallity doesn't matter to get the buggy behavior. Just be ensured that it made more sense in the original context (e.g. it was passed to the utility method and used to setup the delegate object)
> - now there is a category class with a method that invokes the utility method and passing an implicit closure to it (@see CategoryClass#doWorkWithImplicitClosure()). that implicit closure is invoking a method of the delegate object
> - at last the testcase itself will call this category method and assert, that the delegate method was really called by the closure (@see ClosureInsideExtensionOrCategoryTest#testCategoryWithImplicitClosure())
> As you can see in the additional test methods, the basic behavior does work as expected. But only in the special combination of an implicit closure inside of the category it fails.
> As far as I can backtrack it, it seems that the AST-manipulations for category classes may do the damage. It appears to me, that it will manipulate ALL unqualified member-calls inside of any category-methods to be instead calls to the class given by the @Category-annotation. But this manipulation should in my opinion be escaped when entering the code-block of an implicit closure.
> So refering to my example the method CategoryClass#doWorkWithImplicitClosure() seems to lead to the following code after AST-manipulation:
> {code}
> def static doWorkWithImplicitClosure(ExtendedClass obj) {
>   ClosureInvoker.setDelegateAndInvokeClosure {->
>     obj.invokeDelegate()
>   }
> }
> {code}
> This will result in avoiding the whole resolve strategy of the closure, as there won't be any unqualified member calls inside of the closure at all.
> Instead I would expect, that it would generate the following code:
> {code}
> def static doWorkWithImplicitClosure(ExtendedClass obj) {	
>   ClosureInvoker.setDelegateAndInvokeClosure {->
>     //AST manipulation would "prefix" all unqualified 
>     //member calls with "obj." outside of the closure 
>     //but not here as we are inside of a closure
>     invokeDelegate()
>   }
> }
> {code}
> which would be equivalent to ExtensionMethodClass#doWorkWithImplicitClosure(ExtendedClass)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)