groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: @Delegate and Date
Date Tue, 25 Oct 2016 22:16:28 GMT
On 26.10.2016 00:08, wrote:
>> And just to interject the question the OP is probably going to ask:
>> Why should it matter whether it's an "extension" or not?  Is it
>> documented that the methods available on a Delegate exclude what
>> Groovy has added to the class?
> Jochen or someone other probably could give a better explanation, but myself, I would
dare a guess that the problem is that @Delegate is not a true redirector (which I am still
not quite sure is even possible to write Java-side!), but (essentially) a request for the
compiler to add redirection stubs for all the known delegate methods.
> The trick is that Groovy extensions are *not* known methods: they are not part of the
class API, instead, they are added metaclass-level. Thus, the @Delegate AST does not know
of them, and does not add appropriate stubs.

exactly. The same applies to the usage of categories and to methods 
added to the meta class. The problem is reduced if we delegate to the 
implementation of an interface and all the important logic is based on 
the interface type. Because @Delegate per default implements the 
interfaces of the delegates.

> If you stayed completely at the dynamic side instead of using generated stubs through
@Delegate, it would work; on the other hand, it would not work from Java code:
> ===
> class Example {
>     Date when
>     def methodMissing(String name, args) {
>        when."$name"(*args)
>     }
> }
> def x = new Example(when: new Date())
> println  // works
> ===

It is not an either-or. You can do both, causing less load for 
methodMissing and faster dispatch.

> Finally, as for the presumed question whether the @Delegate AST _could_ find the methods
added through extensions... I am not entirely sure. I think it could, but it might get a bit
difficult and perhaps even sort of unreliable. Definitely it would be problematic if called
from Java.

Presuming the availability and usage of certain extension methods is 
imho ok for the static compiler, but not for dynamic Groovy - not if you 
expect a runtime added extension method to have influence

bye Jochen

View raw message