Hello,

thanks a lot for all of your answers and explanations, they were really useful!
Beside using an import alias I found the following „workaround“: If I replace 
the static import in MainClass with a static method pointer like this

class MainClass {
    public static def myMethod = SomeOtherClass.&myBackingMethodThatsNotPublic
   // […]
}

then it’s working as expected. Might be useful, if the names must be identical, 
e.g. in a DSL.

Regards
Johannes

Von: MG <mg...@arscreat.com>
Gesendet: Samstag, 13. April 2019 00:22
An: users@groovy.apache.org
Betreff: Re: Static imports seem to win over a method in closure's delegate

See http://mrhaki.blogspot.com/2009/10/groovy-goodness-static-imports.html

For Web GUI programming we use Groovy together with Vaadin, and I recently had 
some cases, where e.g. an anonymous class method calls a Groovy closure which 
calls a Groovy closure which calls a method of the orginal containing class. In 
these cases it can become hard to have the expected method get called, and I 
also found that (depending on the situation) either using import aliasing or 
introducing a uniquely named helper method in the right class can clear things 
up quick & easy.

Cheers,
mg

On 12/04/2019 23:14, Paul King wrote:
Using import aliases can be a good workaround for such a case.

On Sat, Apr 13, 2019 at 4:58 AM Jochen Theodorou 
<blackd...@gmx.org<mailto:blackd...@gmx.org>> wrote:
On 10.04.19 16:05, Herrendorf Johannes wrote:
> Hi Groovy users,
>
> I’m currently building a DSL in groovy and found some strange behaviour
> I have no explanation for: If a method pointer with name "myMethod" is
> imported as static import and a closure has a delegate with a method
> "myMethod" and it's delegation strategy is set to "DELEGATION_ONLY", the
> imported method is always called inside the closure - the delegate
> property seems to be ignored.

two things to always remember:
* closure delegation is a runtime mechanism, it has no influence on
static compiled features
* static imports are compiled statically

The later is not because we want this, but because we have to more or
less. And it is painful. I can imagine a system where this is not
required, but that is far from easy or efficient.

[...]
> import static mailinglist.SomeOtherClass.myMethod
[...]
>           // dispatched to SomeOtherClass.myMethod; correct
>          myMethod "Hello"
>          closureStuff {
>              // dispatched to SomeOtherClass.myMethod, but I expected that
>                       // it's dispatched to ClosureDelegate.myMethod instead
>              myMethod "Good Morning"
>          }
[...]
> Am I missing something or is this a bug? Thanks for your help in advance!

In short it is a limitation. I am not sure we can really do something
against that.

bye Jochen

Reply via email to