nning processes like editor
From: Jochen Theodorou
Sent: Sunday, February 17, 2019 1:17 PM
To: dev@groovy.apache.org
Subject: Re: [VOTE] Polish the generics type syntax for closure
On 17.02.19 18:31, Milles, Eric (TR Tech, Content & Ops) wrote:
[...]
> So, parser
Just assumed you were thinking of languages that are widely used... ;-)
(Algol type languages are generally not particularily syntax-compatible
with C-style languages in my book).
My suggestion was aimed at not introducing a new syntax variety to
Groovy, while at the same time being more conci
On 17.02.19 18:31, Milles, Eric (TR Tech, Content & Ops) wrote:
[...]
So, parser recovery is new development. And interpretation of new
syntax in the absence of running all AST transforms to completion is new
development.
and is there a way to make things more easy? I mean I would prefer to b
On 16.02.19 19:57, MG wrote:
Hi Daniel,
[...]
I assume Jochen's suggestion is coming from JavaScript/Kotlin, where the
type of a function (method) is given after the colon.
there are many more than just those.
I think its readability is inferior to the C/C++/Java/... approach, and
is only t
Re: [VOTE] Polish the generics type syntax for closure
> It took me a lot of work to support @ClosureParams and @DelegatesTo in
Eclipse. I'm not looking forward to doing it all over again.
The proposed syntax is actually a syntax sugar, which will be transformed to
the current code with a
> It took me a lot of work to support @ClosureParams and @DelegatesTo in
Eclipse. I'm not looking forward to doing it all over again.
The proposed syntax is actually a syntax sugar, which will be transformed to
the current code with annotations finally, so it should not result in much
rework ;-)
items out on Tuesdays so
there is Wed-Fri for people to have a chance to review and ask questions.
From: Daniel.Sun
Sent: Saturday, February 16, 2019 9:46 AM
To: d...@groovy.incubator.apache.org
Subject: [VOTE] Polish the generics type syntax for closure
Dear d
.
From: Milles, Eric (TR Tech, Content & Ops)
Sent: Sunday, February 17, 2019 9:56 AM
To: d...@groovy.incubator.apache.org; dev@groovy.apache.org
Subject: Re: [VOTE] Polish the generics type syntax for closure
It's a -1 for me. It took me a lot of work to support @ClosureP
Hi mg,
I've added your proposed syntax to the GEP, it looks good to me :-)
Cheers,
Daniel.Sun
-
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Added alternative suggestion to use
Closure
https://issues.apache.org/jira/browse/GROOVY-8992?focusedCommentId=16770174&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16770174
Cheers,
mg
On 16/02/2019 18:03, Daniel.Sun wrote:
Hi mg,
I totally understand that
Hi Daniel,
sorry, mixed up aggregated and union types (my son wanted to paly R6).
Corrected and replied.
I assume Jochen's suggestion is coming from JavaScript/Kotlin, where the
type of a function (method) is given after the colon.
I think its readability is inferior to the C/C++/Java/... app
Hi mg,
> I totally understand that you want to move this along, however I have just
> added a comment, suggesting an alternative, more concise syntax, which I
> believe would be worth considering:
Thanks for your suggestion :-)
As | is reserved for Union Type, I'd be inclined to use ; instead of
Hi Daniel,
I totally understand that you want to move this along, however I have
just added a comment, suggesting an alternative, more concise syntax,
which I believe would be worth considering:
Closure
Cheers,
mg
On 16/02/2019 16:46, Daniel.Sun wrote:
Dear development community,
I c
Dear development community,
I completed the GEP for polishing the generics type syntax for closure[1]
just now and happy to start the VOTE thread. The GEP is targeted for Groovy
3.0.0.
The vote is open for the next 72 hours and passes if a majority of at least
three +1 PMC votes are cast.
[ ]
14 matches
Mail list logo
