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:* users@groovy.apache.org; d...@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:* d...@groovy.apache.org; users@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.
>
>

Reply via email to