Re: Groovy Champions proposal feedback

2018-02-16 Thread MG
I do not remember anyone ever listing some negative side effects - very interested to learn about this, since up to now it was only ever "Groovy already has support for that through @Newify" (which I evidently do not agree with :-) ). Apart from that: Much of the Groovy goodness comes from its

Re: Groovy Champions proposal feedback

2018-02-16 Thread MG
On 16.02.2018 01:52, Jochen Theodorou wrote: for the named parameters support the map solution does only not suffice for the static compiler in the end... A pragmatic solution would be to say foo(x:1) can call foo(int) if the parameter is named x and that this call is taken even if there is a

Re: Groovy Champions proposal feedback

2018-02-16 Thread MG
On 16.02.2018 01:52, Jochen Theodorou wrote: final variables with no explicit type not being of type Object is the case for type-checked variant and in normal Groovy it does not play any role (not even the modifier does play a real role in the compilation result) The following holds also for

Inline "Closures" (again)

2018-02-16 Thread MG
Hi Jochen, just to be sure we are on the same page here: The inline "closure" support I currently envision, which basically is to attach the closure body "as is" to an existing language head construct, such as "if"/"for"/"while" could be achieved using a simple text macro. So its not really a

Re: Groovy Champions proposal feedback

2018-02-16 Thread MG
Hi Jochen, On 16.02.2018 01:52, Jochen Theodorou wrote: For me inline closures are not a no-brainer, not at all. just because their solution may look simple does not mean it was easy to develop or that it can be used for Groovy. not being in any way used to thinking about how to extend/improv

Re: @Groovy Champions: Groovy Development Funding ?

2018-02-16 Thread MG
That should be no problem, I would be happy to do a Groovy "thank you" mug o.s.  :-) On 16.02.2018 17:11, Mario Garcia wrote: +1 but also keep in mind that sometimes could be also something as simple as a "grateful box pack" with a T-shirt, sticker or a mug. I would love that too. Mario El

Re: @Groovy Champions: Groovy Development Funding ?

2018-02-16 Thread MG
Positively surprised by the responses so far :-) I agree that one or more concrete goals would be easiest to entice people to fund some development. Batching together multiple goals might have its merits, since it would allow goals with less support to also be funded over time. I hve to date

Re: @Groovy Champions: Groovy Development Funding ?

2018-02-16 Thread Mario Garcia
+1 but also keep in mind that sometimes could be also something as simple as a "grateful box pack" with a T-shirt, sticker or a mug. I would love that too. Mario El 16 feb. 2018 11:49 a. m., "Jochen Theodorou" escribió: > > > Am 16.02.2018 um 03:27 schrieb Paul King: > >> Actually, Apache also

Re: @Groovy Champions: Groovy Development Funding ?

2018-02-16 Thread Jochen Theodorou
Am 16.02.2018 um 03:27 schrieb Paul King: Actually, Apache also accept donations but I think the standard policy is that it isn't then directed back to a specific project. I actually am of the impression that this is the only policy... might be wrong here. I think in general we would be in