Re: SAM type closure coercion

Was that the one case when moaning about other people's work is not frowned upon? Damn, I wish I knew, I would unleash my moaning in public! But seriously, this limitation is very annoying when you work with Ratpack in Groovy. I have moved towards more type safe coding recently and when I learned

Re: The order of modifiers and annotations

On 19.01.2017 08:13, Daniel Sun wrote: Hi all, Currently the old parser allows mixing modifiers and annotations, e.g. *Current* @interface Test1 {} @interface Test2 {} @Test1 final @Test2 a *Suggested* @interface Test1 {} @interface Test2 {} @Test1 @Test2 final a this looks right to

Re: The order of modifiers and annotations

On 19.01.2017 08:22, Daniel Sun wrote: Should we check the redundant modifiers? e.g. *Current* class A { private def a // def is redundant. IMHO, I really don't like it... } *Suggested* class A { private a } def is by now to be thought of as an alias for Object. In that sense it i

Re: The order of modifiers and annotations

> def is by now to be thought of as an alias for Object OK. I see. Thanks :) Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737813.html Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: The order of modifiers and annotations

Sorry for stealing the thread, but there is one annoying thing that relates to parsing modifiers in Groovy. Is there any chance to fix modifier being mandatory for methods with generic signatures in Parrot? I.e. this is now invalid: T foo(T bar) and has to be written like this to be parsed: pub

Re: The order of modifiers and annotations

Yup, we've had this issue for a while https://issues.apache.org/jira/browse/GROOVY-4757 Would be great to fix it with the Parrot parser. On Thu, Jan 19, 2017 at 9:59 AM, Marcin Erdmann wrote: > Sorry for stealing the thread, but there is one annoying thing that > relates to parsing modifiers in

Re: 答复: next releases

Yes, the plan was always to create the 2_5_X branch before releasing 2.5.0-beta-1 and it makes sense to bump master to 3. If there is ever a need for a 2_6_X, that can come later. On Wed, Jan 18, 2017 at 8:22 PM, Cédric Champeau wrote: > I'm +1 on Andrés' plan. Let's have 2_4_X, 2_5_X and `mas

Re: The order of modifiers and annotations

I'll take a look at the issue later. Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737818.html Sent from the Groovy Dev mailing list archive at Nabble.com.

Website deployment

Just a heads-up that the auto website publishing on the CI server was flakey last week - I spoke to a couple of you directly about it - but just to raise awareness I'll repeat here. It started failing a couple of days before I did the last release and without intervention (as far as I know) is fix

Re: The order of modifiers and annotations

I verified that the new parser Parrot does not have the issue( GROOVY-4757 ), the following test case was added in the parrot branch. And I'll resolve the JIRA issue later. https://github.com/apache/groovy/commit/348465a1b193703c43aafeaabf2b2866

Re: The order of modifiers and annotations

Beautiful! thanks again Daniel. One more reason to get 3.0-ea out asap if you ask me ;-) On Thu, Jan 19, 2017 at 12:01 PM, Daniel Sun wrote: > I verified that the new parser Parrot does not have the issue( GROOVY-4757 > ), the following test >

Re: The order of modifiers and annotations

You're welcome :) -- View this message in context: http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737826.html Sent from the Groovy Dev mailing list archive at Nabble.com.

The priority of .. and . (GROOVY-3240)

Hi all, I'm taking a look at GROOVY-3240 , which was raised by me some years ago. I wonder whether .. has higher priority than DOT(.) or not. Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/The-

Re: The priority of .. and . (GROOVY-3240)

Currently .. and ..< have lower priority than . Not sure we should revisit that, it would be a useless breaking change. Integer.metaClass.foo = { delegate + 1 } assert 3.foo()..4.foo() == 4..5 ​ ​ On Thu, Jan 19, 2017 at 1:25 PM, Daniel Sun wrote: > Hi all, > > I'm taking a look at GROOV

Re: The priority of .. and . (GROOVY-3240)

OK. I will close the issue later. Cheers, Daniel.Sun 在 "Guillaume Laforge [via Groovy]" ，2017年1月19日 20:36写道： Currently .. and ..< have lower priority than . Not sure we should revisit that, it would be a useless breaking change. Integer.metaClass.foo = { delegate + 1 } assert 3.foo()..4.foo(

release process

Hi all, since the release did get out, big thanks to Paul here, I think it would be good if the next release could be done by someone else than Paul or Cedric. For example me ;) That is because I would like us to have at least 4 or 5 people being able to do a release. And then there is the qu

Re: release process

+1 with a few comments below. There has been discussion about releases for 2.4.9, 2.5.0-beta-1 and 3.0.0-ea-1. Perhaps we should split between us? I'd suggest I do the first two with you as "co-pilot" and swap roles for the third? Wrt promoting our release process/scripts, I'd probably hold off a