On 25.09.2016 11:59, Krzysztof Kowalczyk wrote:
Thanks Jochen, great idea with charsequence I always forget about its
existence. That works.
By dynamic here I was thinking about methods that call property missing
or generic get/set, so methods that do exist on type are called first
(including those from meta class and extensions).
ok, then let me explain a bit further. There are two types of dynamic
methods.
1) closures acting as methods added to ExpandoMetaClass (EMC). They are
actually almost like normal methods, only that came into existence after
the meta class was created.
2) code called by methodMissing or invokeMethod or any other MOP method.
Those you cannot query, you can only try to invoke and catch the
MissingMethodException.
what is called first and last depends on the MOP method. getProperty for
example is called first, missingProperty last, get I have to lookup.
Additionaly I would like to be able to have such dynamic properties and
methods to take part in static compilation as option. So the whole
example could be run statically. Plus annotation that would be able to
define returned type based on name pattern or groovy Closure.
take part in static compilation... you mean so that the compiler accepts
the code? Because static calls would probably not work. But my question
would be the following... if you know what methods will exist by name
and return type, then why not use @DelegatesTo? Or you need it for
classes and not blocks? Well, then the request would be to create a
@DelegatesTo for classes or something similar, right? Anything more
complicated than that should probably become a type checking extension:
http://docs.groovy-lang.org/next/html/documentation/type-checking-extensions.html
bye Jochen
