Cedric had an idea to include macro methods in 2.5 and re-implement MacroGroovy as a macro method, so I'm reminding everyone about the proposal :)
I'm almost done backporting groovy-macro-methods into the groovy-core, will send PR this week so others can review (it's still WIP tho) On Fri, Sep 23, 2016 at 4:54 PM Sergei Egorov <bsid...@gmail.com> wrote: > Unfortunately, it will not work for 100% cases. > > I.e. macro method accepts ConstantExpression. You can't a method in Groovy > with such constraints. > > Plus, such signature doesn't make sense for IDEs as well, because macro > methods do all the magic when you compile *your* code, not macro method > itself. > > > Sergei > > On Fri, Sep 23, 2016 at 4:46 PM Winnebeck, Jason < > jason.winneb...@windstream.com> wrote: > > Assuming the AST can’t already form the right signature in the JAR for IDE > to see, I can think of one solution: > > > > public class MacroMethods { > > @Macro public static <T> T safe(T param) { > > def ctx = Macros.macroContext > > def exp = Macros.getExpression(param) > > //original code from example… > > } > > } > > > > In this case, the IDE sees a method with an appropriate signature, and > knows the method returns the same type as the argument, but you still have > access to the macro context via static methods which could be implemented > using thread locals or similar. The signature could also be used to > restrict the type of the expression allowed, although in most cases I’d > expect Object or a “T” to be used. > > > > Jason > > > > *From:* Sergei Egorov [mailto:bsid...@gmail.com] > *Sent:* Friday, September 23, 2016 9:27 AM > *To:* us...@groovy.apache.org; dev@groovy.apache.org > *Subject:* Re: Macro methods proposal > > > > Hey Jason, > > > > Left a comment on #3. > > > > Yes, the method signature of Macro methods is not the same as the call > site. But, for the given call site, IDE can easily determine the signature, > and I'm pretty sure it has all the information already. Plus, this is a new > language feature anyway, so IDE will have to support it, at least I see no > other options for now. > > See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about > the syntax as well > > > > Macro methods inherit all the rules of Groovy AST transformations - they > work only for Groovy code. > > > > BR, > > Sergei > > > > > > On Fri, Sep 23, 2016 at 4:02 PM Winnebeck, Jason < > jason.winneb...@windstream.com> wrote: > > 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 > https://github.com/bsideup/groovy-macro-methods-proposal/issues/3. > > > > 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. > > > > Jason > > > > *From:* Sergei Egorov [mailto:bsid...@gmail.com] > *Sent:* Friday, September 23, 2016 5:58 AM > *To:* dev@groovy.apache.org; us...@groovy.apache.org > *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: > > https://github.com/bsideup/groovy-macro-methods-proposal > > > > 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. > > > > > > Cheers, > > Sergei > > 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. > >