groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: Macro methods proposal
Date Fri, 23 Sep 2016 13:01:49 GMT
This is a really cool idea, especially I like the idea of the compile-time checked ORM example.
I wonder whether or not the use in simple cases is productive given JIT inlining and branch
prediction when branching on a constant, and decided to phrase that question in an issue

I noticed that the method signature for the macro method does not match the signature used
at the call site – does this confuse IDEs like IntelliJ, or does this actually work properly
because ASTs must be in a separate JAR, so the @Macro AST has already run to generate a stub
with the proper call signature that the IDE sees?

Last question, is there any interaction with Java? That is, is it possible for an implementation
to provide a “normal” version of the method like in your “warn” example so that Java
can call it as a normal method while in Groovy the transform would be applied? In that way
you could make a logging library that would work like a normal logging library in Java but
in Groovy would apply the macro transformations.


From: Sergei Egorov []
Sent: Friday, September 23, 2016 5:58 AM
Subject: Macro methods proposal

Hey, everyone.

It's been awhile since last time I participated in Groovy.
I was mostly in read-only mode for the last two years.

With this move, I hope to change it.

I created a proposal for macro methods (no ETA, initially aimed to 3.0) because I think they
are great for the future of Groovy and compile time metaprogramming.

You can find the proposal here:

Not sure how Apache people will react on it since it's on GitHub, but it was the simplest
way for me to share and discuss it.

Please note that macro methods are not the same as MacroGroovy - another thing from me already
merged to groovy-core. But, MacroGroovy can and should be implemented with macro methods.

Grammar and clearness are not my strong points, but we can improve the proposal altogether.

For the few years Guillaume, Baruch, Cedric and others were trying to spread the word  about
macro methods, but the problem here that they are something really new and I didn't succeed
explained them back in the days.

So, I'm inviting everyone to discuss them, by raising GitHub issues, or here, in mail list,
to make them more clear for everyone, including end users.


This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.
View raw message