ocals 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
ost 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
>
>
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
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:
://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
roovy 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 no
