groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Krzysztof Kowalczyk <>
Subject Can I force get(String) not to act like propertyMissing?
Date Sat, 24 Sep 2016 23:26:43 GMT

I'm experimenting with @DelegatesTo and other dsl concepts, recently I got a
"problem" with code as in

I have a closure, owner and delegate.
- I want to be able to have dynamic properties resolved on delegate, so
delegate implements propertyMissing
- I want to be able to call methods on owner, so I don't want to resolve
delegate only
- so having both I can't use delegate first as propertyMissing will catch
everything before going to owner

The problem is that I also want to have method called get(String) and this
will be called as a way of resolving dynamic properties. Which is bit
confusing, as there are 2 ways to do the same thing :/ This is not something
that I want. Can I in any way force get(String) not to be counted as
genericGetMethod in metaclass? Maybe magical annotation? I don't see any way
in code. 

I have some possible workarounds in mind:
- change design - so there is no need to call upper scope
- resolve delegate only and create a @Delegate so I have complete control
over methods in scope - so, so
- override getProperty - feels wrong
- put null in genericGetMethod in meta class for the owner -  I guess there
is a special ring in hell for people who do things like that

On the other hand I would like to have is resolution strategy that goes like
- check for real methods in delegate
- check for real methods in owner
- check for dynamic methods in delegate 
- check for dynamic methods in owner

As far as I understand there is no such thing now, right ?


View this message in context:
Sent from the Groovy Users mailing list archive at

View raw message