Re: Lazy evaluation of properties in a closure?

2016-09-23 Thread Andrew Bayer
So of course, right after sending this, I found a workaround for my particular use case - switching from DELEGATE_ONLY to DELEGATE_FIRST got my tests passing. But I'm still curious to know if there's a way to do this in general. =) A. On Fri, Sep 23, 2016 at 9:28 AM, Andrew Bayer

Lazy evaluation of properties in a closure?

2016-09-23 Thread Andrew Bayer
So I've got a DSL that has a section that looks like https://gist.github.com/abayer/a0bfbb531457e79aabc8d6c25d992e62, which ends up translating (via

RE: Macro methods proposal

2016-09-23 Thread Winnebeck, Jason
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… }

Re: Macro methods proposal

2016-09-23 Thread Sergei Egorov
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

Macro methods proposal

2016-09-23 Thread Sergei Egorov
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

Re: JsonOutput serialization options feature

2016-09-23 Thread Graeme Rocher
Great, yeah that would be a big help, since efficiency over the wire for JSON services is a big deal and the unicode escaping doesn't help there. Also, can we consider https://github.com/apache/groovy/pull/429 as an improvement? Again it makes using StreamingJsonBuilder more efficient and