Re: Groovy 4 planning

2019-05-24 Thread Milles, Eric (TR Tech, Content & Ops)
My quick list for Groovy 4: * invoke dynamic by default * incorporate subprojects/parser-antlr4 into root project and drop antlr2 parser * pattern matching / switch expressions (if not already part of Groovy 3) * improved instanceof flow typing: https://issues.apache.org/jira/bro

Re: Groovy 4 planning

2019-05-24 Thread Daniel.Sun
Here is my wish list: * Polish the generics type syntax for closure[1] * Support generics better in static compilation[2] * Implement PIC for better performance[3] * Make groovySh support new features of Groovy3 * Polish bytecode, e.g. eliminate the dead code[4] * Implement GINQ, i.e. Groovy Integr

Re: Groovy 4 planning

2019-05-24 Thread Paolo Di Tommaso
It sounds a good plan! My suggestion is to improve as much as possible the support for native compilation, see for example this thread . There's a lot of excitement in the JVM world at this regard and losing the train can be problematic to k

Re: Groovy 4 planning

2019-05-24 Thread MG
+1 for that, in some cases it is exactly what one needs, and it would be good to have native support for this in Groovy. Thoughts: 1. Maybe put the "s" in front as in "scollect" ? This makes it quicker to get the result with Intellisense (type "sco" instead of "collects") and avoids havin

NV macro status ?

2019-05-24 Thread MG
Hi Paul, come to think of it, what is the status of e.g. the "named variable" macro functionality I did a spike for - do we already have a place where to put such macros to be delivered with Groovy ? As a reminder, e.g. writing: println NV(filteredEntries) would be Groovy-macro-transformed

Re: Groovy 4 planning

2019-05-24 Thread MG
What I would actually have hoped for in Groovy 3: 1. Field/variable type inference outside of flow typing, especially in the case where the variable/field is final. 2. Covariance These are things I encounter constantly as a problem as soon as I switch another class to @CompileStatic. Having