Hi, I'm experimenting with @DelegatesTo and other dsl concepts, recently I got a "problem" with code as in
https://gist.github.com/KrzysztofKowalczyk/bda3bd19cc61b15619e637ccfbb3c26b 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 that: - 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 ? Regards, Krzysztof -- View this message in context: http://groovy.329449.n5.nabble.com/Can-I-force-get-String-not-to-act-like-propertyMissing-tp5735606.html Sent from the Groovy Users mailing list archive at Nabble.com.
