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+
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>
.
>
> -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 >
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
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
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
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
??
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
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
>
>
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
> 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
>>
>>
>
:
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
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
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.
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.
> 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
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
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
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
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
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
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.
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
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
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:
>
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
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.
>
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
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
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
[..]
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
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
> 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
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
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
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
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
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
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
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
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 :
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
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
43 matches
Mail list logo