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 an
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
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
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 safe(T param) {
def ctx = Macros.macroContext
def exp = Macros.getExpression(param)
//original code from example…
}
}
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.
unsuscribe
--
K.Srinidhi,
2nd Year B-Tech,
Amrita School of Engineering,
Kerala,
India.
Phone no:- 9633469368.
