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 <[email protected]>
Gesendet: Samstag, 13. April 2019 00:22
An: [email protected]
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
<[email protected]<mailto:[email protected]>> 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
