答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Daniel Sun
mailto:ml-node+s329449n573848...@n5.nabble.com> 主题: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap) Hi Jesper, Gotcha 😊 For me, I don’t like two versions of lambda expression… it will confuse developers. Cheers, Daniel.Sun 发件人: Jesper Steen Møller [via Groovy]<mailto:ml-node+

答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Daniel Sun
m> 主题: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap) Hi Jesper, Gotcha 😊 For me, I don’t like two versions of lambda expression… it will confuse developers. Cheers, Daniel.Sun 发件人: Jesper Steen Møller [via Groovy]<mailto:ml-node+s329449n573848...@n5.nabble.com>

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Keith Suderman
. > > -Jesper > > >> On 7 Feb 2017, at 14.15, Cédric Champeau > <mailto:cedric.champ...@gmail.com>> wrote: >> >> The result is that the vote turned into a debate again. I give up :) >> >> 2017-02-07 4:18 GMT+01:00 Daniel Sun >

答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Daniel Sun
l.com> 主题: Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap) On 7 Feb 2017, at 16.27, Daniel Sun <[hidden email]> wrote: To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static C

Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Jesper Steen Møller
really interconnected, since the Groovy closure is so versatile to begin with. -Jesper > > > 发件人: [hidden email] > 发送时间: 2017年2月7日 23:10 > 收件人: [hidden email] > 主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap) > > > > (changing the subject so we

答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Daniel Sun
me with us to accept the closure with lambda syntax Cheers, Daniel.Sun 发件人: Jesper Steen Møller [via Groovy]<mailto:ml-node+s329449n5738478...@n5.nabble.com> 发送时间: 2017年2月7日 23:10 收件人: Daniel Sun<mailto:realblue...@hotmail.com> 主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadm

Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Jesper Steen Møller
Daniel.Sun > > > > 发件人: [hidden email] > 发送时间: 2017年2月7日 22:23 > 收件人: [hidden email] > 主题: Re: [VOTE] Apache Groovy Roadmap > > > > > > On 07.02.2017 14:44, Daniel Sun wrote: > > Hi Cédric, > > > > It seems that too

答复: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Daniel Sun
?? Cheers, Daniel.Sun 发件人: Jochen Theodorou [via Groovy]<mailto:ml-node+s329449n5738471...@n5.nabble.com> 发送时间: 2017年2月7日 22:23 收件人: Daniel Sun<mailto:realblue...@hotmail.com> 主题: Re: [VOTE] Apache Groovy Roadmap On 07.02.2017 14:44, Daniel Sun wrote: > Hi Cédric, > > I

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Jesper Steen Møller
o:realblue...@hotmail.com>>: > Hi Cédric, > > 72h has gone. The result is ? > > Cheers, > Daniel.Sun > > > > -- > View this message in context: > http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html > >

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Jochen Theodorou
On 07.02.2017 14:44, Daniel Sun wrote: Hi Cédric, It seems that too many choices are a annoying problem, but I believe we can conquer it sooner or later ;) BTW, is it possible to keep groovy' lambda expression as it is(i.e. groovy closure with lambda syntax) but generate *real* lam

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Cédric Champeau
> The result is that the vote turned into a debate again. I give up :) > > 2017-02-07 4:18 GMT+01:00 Daniel Sun <[hidden email]>: > >> Hi Cédric, >> >> 72h has gone. The result is ? >> >> Cheers, >> Daniel.Sun >> >> >

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Daniel Sun
: Hi Cédric, 72h has gone. The result is ? Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html Sent from the Groovy Dev mailing list archive at Nabble.com. If you re

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Cédric Champeau
The result is that the vote turned into a debate again. I give up :) 2017-02-07 4:18 GMT+01:00 Daniel Sun : > Hi Cédric, > > 72h has gone. The result is ? > > Cheers, > Daniel.Sun > > > > -- > View this message in context: http://groovy.329449.n5. > n

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Paul King
has gone. The result is ? > > Cheers, > Daniel.Sun > > > > -- > View this message in context: > http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html > Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: [VOTE] Apache Groovy Roadmap

2017-02-06 Thread Daniel Sun
Hi Cédric, 72h has gone. The result is ? Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: [VOTE] Apache Groovy Roadmap

2017-02-02 Thread Keith Suderman
> On Feb 2, 2017, at 6:47 AM, Jesper Steen Møller wrote: > > 3. Major numbers should only be used if we mean to break stuff. Parrot > shouldn't. > On Feb 2, 2017, at 10:03 AM, Jochen Theodorou wrote: > > I would like to have a clarification on 2 things before we really make a new > version

Re: [VOTE] Apache Groovy Roadmap

2017-02-02 Thread Jochen Theodorou
I would like to have a clarification on 2 things before we really make a new version: * is changing to java7 as default a breaking change and requires a new major version? (that implies 3.0 soon and 4.0 for java8 not long after) * is it acceptable to have optional java8 only components (for exa

Re: [VOTE] Apache Groovy Roadmap

2017-02-02 Thread Daniel Sun
O, I do not approve the roadmap abobe beause... > - [ ] I don't mind, or this goes beyond what I can think of > > This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017. > ________ If you reply to this email, your message will be added to the discu

Re: [VOTE] Apache Groovy Roadmap

2017-02-02 Thread Graeme Rocher
I'm in agreement that we should not commit to behaviour that we believe to be wrong and later break it (i.e. lambda's) So if we agree on a version that should be "the Parrot release" whether that is 2.6 or 3.0 we have to scope into that work resolving the semantics discussion. Cheers On Thu, Feb

Re: [VOTE] Apache Groovy Roadmap

2017-02-02 Thread Jesper Steen Møller
Hi list > On 2 Feb 2017, at 11.58, Paul King wrote: > > This thread has kind of gone into debate mode but I guess for the > record I would be -1 on any releases having parrot that weren't marked > as "experimental" or "incubating" until we thrash out future plans for > dealing with Java 8 featur

Re: [VOTE] Apache Groovy Roadmap

2017-02-02 Thread Paul King
This thread has kind of gone into debate mode but I guess for the record I would be -1 on any releases having parrot that weren't marked as "experimental" or "incubating" until we thrash out future plans for dealing with Java 8 features (default methods on interfaces/"real" lambda expressions). I d

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Daniel Sun
ope your program conforms to GLS too ;) Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738282.html Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Suderman Keith
No. I would like to vote YES as this is almost what I proposed in the "release process" thread, but I think I'm going to have to vote NO as there are potential breaking changes in 2.5 (requiring Java 1.7) and 2.6 (switching to Parrot). Hopefully Parrot doesn't break anything, but I don't know

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Guillaume Laforge
YES (binding) On Tue, Jan 31, 2017 at 9:37 AM, Cédric Champeau wrote: > Hi guys, > > There are multiple conversations going on for weeks, and I think they are > going nowhere. We could discuss for months what's the best plan for Groovy, > without releasing anything. Here are the challenges that

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Bahman Movaqar
On 01/31/2017 09:37 AM, Cédric Champeau wrote: > Hi guys, > > There are multiple conversations going on for weeks, and I think they > are going nowhere. We could discuss for months what's the best plan for > Groovy, without releasing anything. Here are the challenges that are > waiting for us: >

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Russel Winder
On Tue, 2017-01-31 at 09:37 +0100, Cédric Champeau wrote: > […] > > - [ ] YES, I approve the roadmap above > - [ ] NO, I do not approve the roadmap abobe beause... > - [ ] I don't mind, or this goes beyond what I can think of > > This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017. YE

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Cédric Champeau
g changes. > If program has already used "macro" method name, what will happen? > > Cheers, > Daniel.Sun > > > > -- > View this message in context: http://groovy.329449.n5. > nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738271.html > Sent from the Groovy Dev mailing list archive at Nabble.com. >

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Daniel Sun
Hi Cédric, > Because macro groovy doesn't have to be bound with breaking changes. If program has already used "macro" method name, what will happen? Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Graeme Rocher
YES from me. IMO we should not be waiting until 3.x for Parrot however, I am also ok with the proposal to change the roadmap so that Groovy 3.x is the Parrot release and Groovy 4.x the breaking Jigsaw/Java 8/9 release. The sooner we get folks testing Parrot in the real world the better and if we

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Sven Reimers
I would be volunteering for checking if this is a problem in NetBeans Groovy Support. What are the patterns I should look for? Already any branch I could build and try as an experiment? Thanks Sven Am 31.01.2017 12:46 schrieb "Jochen Theodorou" : > [..] > >> Were exactly was this leak? The ant

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Jochen Theodorou
[..] Were exactly was this leak? The antlr2 classes are jarjar'ed, right - they were hardly API. Or am I missing something? As for usage: A quick search on GitHub for the string 'groovyjarjarantlr' revealed 12 commits, most of them in Adempiere and 'groovy-class-parser', in pretty old code. I a

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Jochen Theodorou
On 31.01.2017 11:11, Remi Forax wrote: [...] Jigsaw is more or less forward compatible, i.e. you can release jars that will use Java 8 to compile (or Java 9 in release mode 8) and also make them jigsaw compatible in term of dependencies. Obviously the module graph will be read only on Java 9 bu

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Remi Forax
> De: "Alessio Stalla" > À: dev@groovy.apache.org > Envoyé: Mardi 31 Janvier 2017 11:04:00 > Objet: Re: [VOTE] Apache Groovy Roadmap > Sorry if outsiders are not meant to chime in :) > Why not > - 2.5 as Cédric proposed (so Java 7 + macros) > - 3.0 with Java 8

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Jesper Steen Møller
On 31 Jan 2017, at 10.46, Jochen Theodorou wrote: > > > On 31.01.2017 09:37, Cédric Champeau wrote: >> >> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7 >> - Groovy 3.0: integrate 3 and 5. The only version with necessary >> breaking changes (we have no choice here) > > If you

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Alessio Stalla
Sorry if outsiders are not meant to chime in :) Why not - 2.5 as Cédric proposed (so Java 7 + macros) - 3.0 with Java 8 and Parrot - 4.0 with Java 9 and Jigsaw? This way Groovy versions and Java versions are nicely aligned. To let people try Parrot early, there could be a 3.0 early access rele

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Cédric Champeau
2017-01-31 10:46 GMT+01:00 Jochen Theodorou : > > > On 31.01.2017 09:37, Cédric Champeau wrote: > >> Hi guys, >> >> There are multiple conversations going on for weeks, and I think they >> are going nowhere. We could discuss for months what's the best plan for >> Groovy, without releasing anything

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Jochen Theodorou
On 31.01.2017 09:37, Cédric Champeau wrote: Hi guys, There are multiple conversations going on for weeks, and I think they are going nowhere. We could discuss for months what's the best plan for Groovy, without releasing anything. Here are the challenges that are waiting for us: 1. release a

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Andres Almiray
Having Parrot available for immediate testing is the reason why I'd advocate for having 3.0-ea releases ;-) --- Java Champion; Groovy Enthusiast http://jroller.com/aalmiray http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system a

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Andres Almiray
In principle I'd say YES but I don't agree on Parrot being backported to 2.6 due to potential incompatibilities. I don't want users to have the same pain we had when switching between Groovy 1.7 and 1.8. IMHO Parrot should go on 3.x, thus the only parts of the roadmap I can safely vote YES are #1 a

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Søren Berg Glasius
YES (not binding). This is a clear plan, and is easy to understand for the community. It makes way for a 2.5 soon, and it also puts Parrot in a release that is not too far into the future, which IMO is important. IMO a good plan. On Tue, 31 Jan 2017 at 09:45 Cédric Champeau wrote: > YES for me

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Cédric Champeau
YES for me too (forgot to answer :D). And yes, we should review (and merge) your PR before beta-1. 2017-01-31 9:44 GMT+01:00 Sergei Egorov : > YES from me. > > Would be great if we can deliver #1 as a macro method, not it form of > "MacroGroovy" (and hopefully forget this awkward name collision :

Re: [VOTE] Apache Groovy Roadmap

2017-01-31 Thread Sergei Egorov
YES from me. Would be great if we can deliver #1 as a macro method, not it form of "MacroGroovy" (and hopefully forget this awkward name collision :D ) Just want to remind that there is a PR waiting for a review where I rewrote it and implemented basic macro methods support: https://github.com/ap

[VOTE] Apache Groovy Roadmap

2017-01-31 Thread Cédric Champeau
Hi guys, There are multiple conversations going on for weeks, and I think they are going nowhere. We could discuss for months what's the best plan for Groovy, without releasing anything. Here are the challenges that are waiting for us: 1. release a version of Groovy that integrates Groovy macros