groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Krzysztof Kowalczyk <>
Subject Re: Can I force get(String) not to act like propertyMissing?
Date Wed, 28 Sep 2016 09:47:26 GMT
Hi Jochen,
> 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.

I get that. It just would feel better to me if the 1st category could be
evaluated on both owner and delegate before going to 2. Don't know if there
is something technical that would make it a bad idea. But it is not a big
deal and I don't really need it, just thinking aloud. 
> take part in static compilation... you mean so that the compiler accepts
> the code? Because static calls would probably not work.

If I have a 

class A { 
 String porpertyMissing(String){}

I would like to have option to static compile a closure which delegates to
{ println key;} 

so it would be accepted even if @CompileStatic is used and compiled to:

  println porpertyMissing("key")

As this is not trivial to decide what is actually called I would see it as
something what need to be explicitly turned on. Possibly providing some
additional details. The order of get, propertyMissing etc should be resolved
as usual, or decided what to do in annotation. I wonder how far I could push
something like that, maybe one could define the actual pattern for generated
names for better stronger typing and better ide support, i.e.:

// long types name to better describe idea
def methodMissing(name, args)
Where type could be regex or something simpler, with pluggable strategies
for name and method arguments.
I would have to check feasibility of something like that on example, guess
GORM is a good real life test.

I haven't used type checking extensions yet so I am not sure what can be
done there.


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

View raw message