[groovy-macro] static method call expressions

[Mario Garcia]

Hello:

I'm playing a little bit with groovy-macro, BTW it's really cool how easy
you can create statements and expressions.

However I'm having some issues when trying to create an static method call:

*Statement callJsonOutput(final MapExpression mapExpression) {*
*return macro(true) { JsonOutput.toJson($v{ mapExpression }) }*
*}*

When executing the test, it complains because "JsonOutput" class is not
found. That's correct, but I can't make it work either by doing:

*Statement callJsonOutput(final MapExpression mapExpression) {*
*return macro(true) { groovy.json.JsonOutput.toJson($v{
mapExpression }) }*
*}*

Any ideas ?
Mario

Re: Pull request to make private methods static when they are plain functions

[Mario Garcia]

Thanks for the clarification :)
On 28 Apr 2016 02:12, "John Wagenleitner" <john.wagenleit...@gmail.com>
wrote:

>
>
> On Sun, Apr 24, 2016 at 11:13 PM, Mario Garcia <mario.g...@gmail.com>
> wrote:
>
>> +1
>>
>> Besides, I was wondering If most, if not all these static methods, should
>> have all parameters marked as final. Is there any policy about this ? Would
>> it help ?
>>
>
>
> I don't think there's a policy, personally I tend to not use final for
> local/parameters unless it's used in an anonymous inner class.  Hopefully
> the methods are short enough that the extra syntax is not needed to know if
> it reassigned or not.
>
>
>>
>> 2016-04-24 21:46 GMT+02:00 Jochen Theodorou <blackd...@gmx.org>:
>>
>>> On 24.04.2016 18:12, John Wagenleitner wrote:
>>>
>>>> About to merge in PR 290 [1] and wanted to do a quick poll to see if
>>>> there were any objections since it touches quite a few files across core
>>>> and sub-modules.  Any objections to merging this into master?  And
>>>> GROOVY_2_4_X?
>>>>
>>>> [1] https://github.com/apache/groovy/pull/290
>>>>
>>>
>>> I guess it is ok. I did see two package private methods made private
>>> instead of only private ones, but even those should be ok. so unless I did
>>> oversee something I do not really have any objection here.
>>>
>>> bye Jochen
>>>
>>
>>
>

Re: Pull request to make private methods static when they are plain functions

[Mario Garcia]

+1

Besides, I was wondering If most, if not all these static methods, should
have all parameters marked as final. Is there any policy about this ? Would
it help ?

2016-04-24 21:46 GMT+02:00 Jochen Theodorou :

> On 24.04.2016 18:12, John Wagenleitner wrote:
>
>> About to merge in PR 290 [1] and wanted to do a quick poll to see if
>> there were any objections since it touches quite a few files across core
>> and sub-modules.  Any objections to merging this into master?  And
>> GROOVY_2_4_X?
>>
>> [1] https://github.com/apache/groovy/pull/290
>>
>
> I guess it is ok. I did see two package private methods made private
> instead of only private ones, but even those should be ok. so unless I did
> oversee something I do not really have any objection here.
>
> bye Jochen
>

Re: Problem creating groovy-macro spec files

[Mario Garcia]

I'm debugging now *Groovy7316Bug*

So far, the test passes if we assume that the AST should be correct in a
later phase:

void testTypeCheckingBypassUsingExplicitTypeHint() {
assertScript '''
public  T getSomething() { null }

public List getList() {
@ASTTest(phase=FINALIZATION,value={
def ift = node.getNodeMetaData(INFERRED_TYPE)
def makeList = make(List)

assert ift == makeList
})
def list = this.getSomething()
}
'''
}

The tests fails if we assume both expressions should return the same value
at SEMANTIC_ANALYSIS phase.

2016-05-22 16:05 GMT+02:00 Guillaume Laforge <glafo...@gmail.com>:

> You might want to ping Sergei, Groovy Macro's creator.
> I've added Sergei in CC.
>
> Guillaume
>
> On Sun, May 22, 2016 at 3:29 PM, Mario Garcia <mario.g...@gmail.com>
> wrote:
>
>> Yep, that's what I thought, but I was hoping somebody telling me It was
>> my fault :P
>>
>> I'll take a further look to see if I'm able to see what's happening.
>> Thanks anyway :)
>>
>> 2016-05-22 15:25 GMT+02:00 Pascal Schumacher <pascalschumac...@gmx.net>:
>>
>>> Hi Mario,
>>>
>>> as far as I remember groovy-macro is global ast-transformation. I guess
>>> here is some side-effect/bug which causes the test failures. Sadly I lack
>>> the necessary knowledge to investigate further.
>>>
>>> -Pascal
>>>
>>>
>>> Am 22.05.2016 um 14:33 schrieb Mario Garcia:
>>>
>>> Hi:
>>>
>>> I'm trying to write some examples about the new features coming in the
>>> new 'groovy-macro' but I'm experiencing some issues.
>>>
>>> In order to use 'groovy-macro' in the specs I've added the following
>>> line in the root build.gradle:
>>>
>>>testCompile project(':groovy-macro')
>>>
>>> But when running tests using "./gradlew test" two tests are failing:
>>>
>>>-
>>>
>>> org.codehaus.groovy.classgen.asm.sc.bugs.Groovy6757Bug#testExplicitTypeHint
>>>-
>>>
>>> org.codehaus.groovy.classgen.asm.sc.bugs.Groovy7316Bug#testTypeCheckingBypassUsingExplicitTypeHint
>>>
>>> I've removed my examples to isolate the issue. And it turns out it just
>>> fails adding the testCompile dependency. Once I remove the dependency all
>>> tests succeed.
>>>
>>> Any ideas ? Should I've been doing the dependency management in some
>>> other way? Maybe a bug ?
>>>
>>> Mario
>>>
>>>
>>>
>>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Product Ninja & Advocate at Restlet <http://restlet.com>
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Re: http://www.groovy-lang.org/ down

[Mario Garcia]

Thanks for the explanation Guillaume.

Just a quick question. I was wondering if, the same way Groovy has a mirror
in Github, could it be possible to have the Groovy site published as a
gh-pages? That would work as a possible documentation back-up in the
future. Of course I don't mean to do it any time soon, but it could be a
nice (partial) solution if any of this happens again in the future.

Mario

2016-05-22 20:20 GMT+02:00 Guillaume Laforge :

> And... it's back now!
>
> Sorry again for the inconvenience, but this was really beyond our control
> unfortunately.
>
> Regarding your points, Steve:
>
> 1) If a company is stupid to "abandon" a great language like Groovy, too
> bad for them ;-)
>
> 2) Well, we can't control perception obviously, and I didn't envision a
> simple DNS domain name transfer would fail so bad. Normally, this kind of
> process should really be smooth. So it's really really unfortunate that the
> ASF infra couldn't handle that appropriately and timely. To their defense,
> it's mostly a team of non-paid volunteers, relying on services granted for
> free by third-parties, and in this instance, it was really not a smooth and
> reliable process.
>
> 3) We're at the wheel, don't worry, even if not full time like we used to.
> Reverting the process wasn't possible, as once you've made the move to
> transfer a domain name, you can't take it back, so I couldn't have been
> able to reclaim it. And since the Apache foundation mandates that such
> domain names be in their control, we would have had to go through that
> process anyway. So reverting to try again later would have run the risk of
> two such downtimes, which would be even worse.
>
> Guillaume
>
> On Sun, May 22, 2016 at 4:39 PM, Steve Byrne  wrote:
>
>> What about backing out the change for now?  This is looking really
>> bad...think about how it looks from the outside:
>>
>> 1) Pivotal appears to "abandon" Groovy as a language -- does not send a
>> positive signal about the language's future prospects
>>
>> 2) _Without warning_ the groovy-lang.org site *DISAPPEARS*.   "Oh
>> well,", people think, "looks like Groovy is done for.  _Glad we did not
>> make that decision to depend on Groovy for our go-forward technology_"
>>
>> 3) The problem isn't being corrected.  This looks like either a) nobody
>> is "a the wheel" (of the car), or b) the folks behind Groovy (whomever they
>> are, again I am speaking as it would appear to the outside) are just really
>> incompetent, and again "we're glad we did not decide to invest development
>> resources into using Groovy", or, "Wow, after Pivotal abandoning Groovy,
>> and now the whole Groovy lang site disappearing _in the middle of the
>> night_", we'd better move off Groovy -- too much risk"
>>
>> *It's time to back out this change*.  Get groovy-lang.org back on the
>> air ASAP!  Let Apache figure out their issue in parallel, but don't leave
>> this gaping and bleeding wound untreated any longer.  It really looks bad,
>> and I think still at this point, Groovy as a language/runtime/technology
>> cannot afford to look bad, after item 1 above happened.
>>
>> I really like Groovy and would hate to lose it because of this silly
>> indecent.  And, not having access to groovy-lang.org (and all the docs
>> about the GDK) is hampering my development (yeah, I could have a local
>> copy, that I replicate onto _each_ of my machines and keep up to date, but
>> why bother?).
>>
>> Here's hoping you make the right decision,
>> Steve
>>
>> On May 22, 2016, at 5:11 AM, Guillaume Laforge 
>> wrote:
>>
>> Hi Pascal,
>>
>> Yes, please see my messages to the users list.
>>
>> Here's the Apache Infra ticket tracking this:
>> https://issues.apache.org/jira/browse/INFRA-11843
>>
>> We've launched the transfer of the domain name to the ASF, but
>> unfortunately, this is not yet resolved :-(
>>
>> It's becoming painful, to say the list, and I get inquiries through
>> emails, twitter and elsewhere about it... I hope the Infra team will be
>> able to resolve that soon. It's already been so long :-(
>>
>> Guillaume
>>
>> On Sun, May 22, 2016 at 2:08 PM, Pascal Schumacher <
>> pascalschumac...@gmx.net> wrote:
>>
>>> Hello everybody,
>>>
>>> http://www.groovy-lang.org/ seems down since Friday?
>>>
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Product Ninja & Advocate at Restlet 
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge  / Google+
>> 
>>
>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Product Ninja & Advocate at Restlet 
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: Problem creating groovy-macro spec files

[Mario Garcia]

BTW I'm using

Linux Debian
open-jdk 1.8.0_72

2016-05-22 14:33 GMT+02:00 Mario Garcia <mario.g...@gmail.com>:

> Hi:
>
> I'm trying to write some examples about the new features coming in the new
> 'groovy-macro' but I'm experiencing some issues.
>
> In order to use 'groovy-macro' in the specs I've added the following line
> in the root build.gradle:
>
>testCompile project(':groovy-macro')
>
> But when running tests using "./gradlew test" two tests are failing:
>
>-
>org.codehaus.groovy.classgen.asm.sc.bugs.Groovy6757Bug#testExplicitTypeHint
>-
>
> org.codehaus.groovy.classgen.asm.sc.bugs.Groovy7316Bug#testTypeCheckingBypassUsingExplicitTypeHint
>
> I've removed my examples to isolate the issue. And it turns out it just
> fails adding the testCompile dependency. Once I remove the dependency all
> tests succeed.
>
> Any ideas ? Should I've been doing the dependency management in some other
> way? Maybe a bug ?
>
> Mario
>
>
>

Re: [Question] The Apache Groovy Language Reference

[Mario Garcia]

Hi:

There is also a single page document at
http://groovy-lang.org/single-page-documentation.html

Mario

2016-05-23 10:59 GMT+02:00 Duncan Dickinson :

> Hi Edinson,
>
> The main documentation is at http://groovy-lang.org/documentation.html
> and includes language specification sections. Is that what you're after?
>
> Cheers,
>
> Duncan
>
> Sent from my iPad
>
> On 23 May 2016, at 18:44, Edinson E. Padrón Urdaneta <
> edinson.padron.urdan...@gmail.com> wrote:
>
> Greetings Apache Groovy Community,
>
> I was wondering if we have a manual that describes the syntax and
> semantics of the language. Something like Python's [1].
>
> Thank you all for your time in advance.
>
> [1] https://docs.python.org/3/reference/index.html
>
>

Re: Progress on the Antlr4-based parser update(2016.04.30)

[Mario Garcia]

Very impressive work! Congrats!
On 30 Apr 2016 17:32, "Jochen Theodorou"  wrote:

> yes, they are doing a really nice job on this. I am very happy for them to
> invest so much time here
>
> bye Jochen
>
> On 30.04.2016 13:06, Guillaume Laforge wrote:
>
>> Great progress guys! This is awesome and shaping up nicely!
>>
>> Guillaume
>>
>> Le 30 avr. 2016 11:27 AM, "daniel_sun" > > a écrit :
>>
>> Hi Groovy-Dev,
>>
>>  Since Jesper reported the progress last time, Jesper and I have
>> refined
>> the new parser for Groovy programming language in many aspects,
>> which now
>> can handle almost all source code of Groovy in Action 2nd
>> Edition(633 passed
>> / 635 total, including our own 72 test cases). The following list
>> shows our
>> main work ( https://github.com/jespersm/groovy/commits/antlr4 ):
>>
>> 1)  Support Traits
>> 2)  Support Tuple
>> 3)  Support Labeled statement
>> 4)  Support multi-dimensional array
>> 5)  Support inner enum
>> 6)  Support annotations added for declaration statement
>> 7)  Full Unicode letter support for identifiers
>> 8)  Proper unescaping of string literals
>> 9)  Support named parameter with closures
>> 10) Support var-args
>> 11) Support synchronized statement
>> 12) Import statements, script, declaration and types can be mixed
>> with each
>> other
>> 13) Add missing keywords and built-in types
>> 14) Support binary literals
>> 15) Allow enum constants with parameters
>> 16) Make strict check for def and modifiers, which should not be
>> duplicated
>> 17) Allow defining method whose name is non-IDENTIFIER
>> 18) Allow invoking method with optional parentheses
>> 19) Support dollar slashy string
>> 20) Refine strings recognition and process
>> 21) Support expressions and statements spanning rows
>> 22) Fix a lot of bugs(including [GROOVY-7765]Dollar Slashy String in
>> assert
>> not working left hand side)
>>
>> Our next target is listed as follows. In addition, we plan
>> to add
>> grails-core-3 source code as test cases.
>> 1) Support command expression( Jesper has started to try to complete
>> it )
>> 2) Verify operator precedence
>> 3) Friendly prompt messages
>> 4) Support lamda expression
>> 5) Support do-while, the basic control structure like java's
>>
>>Finally, we will thank Jochen who gives us many support and
>> useful
>> advices, Cédric who provides us a new CI server :-)
>>
>> p.s. If you want to play with the new parser, try:
>>
>> $ git clone -b antlr4 https://github.com/jespersm/groovy.git
>> $ cd groovy
>> $ gradle -PuseAntlr4=true console
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>>
>> http://groovy.329449.n5.nabble.com/Progress-on-the-Antlr4-based-parser-update-2016-04-30-tp5732616.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>>
>>
>

Re: Automatic closure coercion and delegate

[Mario Garcia]

+1

2016-05-03 10:29 GMT+02:00 Jochen Theodorou :

> On 03.05.2016 08:26, Cédric Champeau wrote:
> [...]
>
>> repositories { // Action> maven { Action
>>  url ''
>> }
>> }
>>
>
> I see... I would feel much better if this was done by a special interface,
> coming from Groovy... maybe even a trait. But I guess this is not really an
> option.
>
> [...]
>
> Doing the same for abstract classes should be straightforward. For
>> static compilation, it's going to be more complicated and probably
>> requires transparently invoking a configurer (like Gradle does).
>>
>
> the proxy generation will work the same, I guess you are talking about the
> direct method calls inside the closure as well es letting it pass static
> compilation. But I still don't understand what you mean by configurer
>
> bye Jochen
>
>
>

Re: [groovy-macro] static method call expressions

[Mario Garcia]

I figured out why:

By default macros are using CompilePhase.CONVERSION and at this point the
compiler doesn't care about types. That's why it didn't recognized neither
"JsonOutput" (When using JsonOutput.toJson...) nor "groovy" (When using
groovy.json.JsonOutput.toJson...):

The way it's working now is:

Statement stmt = macro(CompilePhase.SEMANTIC_ANALYSIS, true) {
groovy.json.JsonOutput($v{mapExpression})
}

or...

MethodCallExpression methodCall = macro(CompilePhase.SEMANTIC_ANALYSIS) {
groovy.json.JsonOutput($v{mapExpression})
}

...in case you wanted to get the method call expression directly.
Mario

2016-04-11 14:26 GMT+02:00 Mario Garcia <mario.g...@gmail.com>:

> Hello:
>
> I'm playing a little bit with groovy-macro, BTW it's really cool how easy
> you can create statements and expressions.
>
> However I'm having some issues when trying to create an static method call:
>
> *Statement callJsonOutput(final MapExpression mapExpression) {*
> *return macro(true) { JsonOutput.toJson($v{ mapExpression }) }*
> *}*
>
> When executing the test, it complains because "JsonOutput" class is not
> found. That's correct, but I can't make it work either by doing:
>
> *Statement callJsonOutput(final MapExpression mapExpression) {*
> *return macro(true) { groovy.json.JsonOutput.toJson($v{
> mapExpression }) }*
> *}*
>
> Any ideas ?
> Mario
>

[AST] Is there any way to remove an AnnotationNode from an AnnotatedNode ?

[Mario Garcia]

I don't know how to do this. Looking the g/api there is a "addAnnotation"
but there is not a "removeAnnotation" like method.

Mario

Re: [AST] Is there any way to remove an AnnotationNode from an AnnotatedNode ?

[Mario Garcia]

Oh I didn't know that. Thank you Shil :)

2016-04-20 16:20 GMT+02:00 Shil Sinha <shil.si...@gmail.com>:

> The annotationNodes list for an AnnotatedNode is accessible and and
> mutable so you should be able to remove it yourself.
>
> On Wed, Apr 20, 2016 at 7:56 AM, Mario Garcia <mario.g...@gmail.com>
> wrote:
>
>> I don't know how to do this. Looking the g/api there is a "addAnnotation"
>> but there is not a "removeAnnotation" like method.
>>
>> Mario
>>
>
>

Groovy macro documentation

[Mario Garcia]

Hi all:

I sent a WIP with some groovy-macro documentation. The main problem with
the PR is that there're two tests failing. I've been checking tests code
and I can't see anything that may cause these tests to fail.

I'll be reviewing the whole thing during the weekend but it would be better
if anyone else could look into this.

Of course I'd love to receive feedback related to the documentation. I'm
sure there must be some typos, or something that should be explained
better...

Cheers
Mario

Re: [VOTE][LAZY] Apache Groovy Roadmap - take 2

[Mario Garcia]

+1

On 16 Mar 2017 15:29, "Guillaume Laforge"  wrote:

> +1
>
> On Wed, Mar 15, 2017 at 4:15 AM, Paul King  wrote:
>
>> Hi folks,
>>
>> Earlier in the year, Cédric did a great job of outlining a possible
>> roadmap for Groovy. I think there was general consensus on most of it
>> but we never quite managed complete consensus.
>>
>> We had a fairly clear consensus on getting out 2.5 with macro support
>> - that is underway now.
>>
>> There was also consensus around a version of Groovy containing the new
>> parrot parser and based around a minimum JDK runtime requirement of
>> 1.8 (possibly numbered Groovy 3.0 or 4.0). This is what we'll start
>> fleshing out on the master branch.
>>
>> I believe there was also general consensus around a version of Groovy
>> containing a back-ported version of the parrot parser for jdk 1.7
>> (possibly numbered Groovy 2.6 or 3.0).
>>
>> The main contention seemed to be what level of breaking changes (if
>> any) should be allowed in a 2.6 release (vs 3.0 release) etc. I don't
>> believe there was a serious divide in opinions, just that without some
>> more concrete details about what would actually be in any of the
>> various proposed releases, it was difficult to zero in on a final
>> roadmap.
>>
>> Rather than continue debate at a theoretical level about the roadmap,
>> I plan to just start fleshing out some more details of the potential
>> releases and we can decide when to release and what to call them once
>> they are fleshed out further.
>>
>> With this in mind, I plan to create a 2_6_X branch. The intention will
>> be to try out the back-ported parrot to convince ourselves if any
>> (significant) breaking changes have been introduced - and
>> (potentially) exclude some of Parrot's changes. This branch can be
>> considered a bridging version of Groovy for JDK 1.7 users who can't go
>> straight to the full 1.8 based version. We can decide later whether
>> this branch forms the basis of a 2.6, 3.0 or no release.
>>
>> This is a lazy consensus vote, so I'll go ahead and create the branch
>> in 72 hrs for the purposes described above unless I hear serious
>> objections.
>>
>> Cheers, Paul.
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: The new annotation Groovydoc for Groovy 3

[Mario Garcia]

Thanks for the pointer! I'll take a look at it

Mario

2017-04-10 8:56 GMT+02:00 Daniel Sun :

> Hi Mario,
>
>  Here is the background of the new annotation:
>
> About a new annotation Groovydoc
> http://groovy.329449.n5.nabble.com/About-a-new-annotation-Groovydoc-
> tp5738721.html
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/The-new-annotation-Groovydoc-for-Groovy-3-
> tp5739731p5739736.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Re: The new annotation Groovydoc for Groovy 3

[Mario Garcia]

Very interesting Dani.

Although I can think myself a couple of use cases for this, I'm intrigued,
where did this come from ? What was the scenario you had in mind ?

On 10 Apr 2017 02:26, "Daniel Sun"  wrote:

We can call it "Runtime Groovydoc".



--
View this message in context: http://groovy.329449.n5.
nabble.com/The-new-annotation-Groovydoc-for-Groovy-3-tp5739731p5739733.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: master branch has had the 'parrot' branch merged

[Mario Garcia]

Great news :)

Great work guys!!

2017-04-11 3:49 GMT+02:00 Paul King :

>
> Hi all,
>
> I merged the parrot branch into master. All the tests pass.
>
> I'll split off the GROOVY_2_6_X branch next week (the idea of that branch
> is outlined in earlier emails) and merge in the parrot backport before
> bumping master to jdk8.
>
> Daniel, we'll need to do some re-work wrt to the zips in:
> subprojects/groovy-parser-antlr4/src/test/resources
>
> We can't have those zips embedded within the src zip we use for
> distribution (Apache policy). Rat currently doesn't check that subproject.
> It seems useful to still have those tests though, so we need to (logically
> at least) "move them off to the side" somehow. Several ways we can do it. I
> can assist next week when I get back from holidays if you don't have any
> luck in the meantime.
>
> Cheers, Paul.
>

Re: Build failing

[Mario Garcia]

+1 to what Russel said. Maybe given one example the rest can follow your
steps.

And course +1 to change whatever is necessary from your point of view.

El 17 jun. 2017 1:18 p. m., "Russel Winder"  escribió:

> On Sat, 2017-06-17 at 09:44 +0200, Cédric Champeau wrote:
> > Yes, there are apparently quite a few glitches after the upgrade.
>
> OK, it's not just me then. Which is good. Sort of.
>
> > Dear community, please give me the strength to rewrite this whole
> > build.
> > Need to make it cleaner, it accumulated too many years of hacking,
> > inherited from the Ant era. Time to do some cleanup!
>
> I think we have a Maven build after the Ant one and before the Gradle
> one. I know, I started it. :-)
>
> Also there was the modular rewrite, which put some hacks in along with
> the JDK version stuff.
>
> If you can put in place an overall new architecture for a Gradle 4.0
> build, and do an exemplar "module" then many of us can chip in doing
> the leg-work of all the other "modules". Also if there is a repository
> to clone and work in which is not the mainline, it can be cloned and
> builds tried.
>
> We are here to help, you are not alone.
>
> --
> Russel.
> 
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: What the... static compile by default

[Mario Garcia]

*About Static Compilation changes:*

I've used the way it's documented in the official documentation, and I
agree with Cedric, I don't like having a system property. I see more
benefits using the compiler configuration file:

   - Configuration is more fine grained (apply to all, apply to some
   classes, apply to some packages...)
   - All compilation configuration can be found in one place. Having more
   than one place to do this could be error prone, and harder to maintain.
   - System properties are normally used when the process should vary
   depending on the environment. In this case, I'm wondering why I would want
   to compile my code statically in one environment but dynamically in
   another. Maybe there is a case for that, but to me is weird.

*About Daniel response:*

I'm so sad to hear that Daniel. In the past few years I've been hearing
only amazing things coming from your contributions.  Like someone has
mentioned, Groovy 3 wouldn't be the same without you. I really hope you
could reconsider your decision and keep contributing to Groovy.

*About doing commits on master:*

Reading the "Contributing code" section, at groovy-lang.org it seems
everybody should be creating a local branch and to a MR afterwards over the
remote version of that local branch. So  (again, reading the
documentation)  nobody should be adding commits to master directly.

I think merge requests are essential. I'm reading Jochen is saying that
this is not very straight forward with Github. Could anyone please explain
why ? Knowing the pains may help finding the solution.

My two cents
Mario

El vie., 11 may. 2018 3:42, Thibault Kruse 
escribió:

> It seems a bit weird to leave this thread dangling after the dramatic
> entry scene.
>
> The activity on master branch seems to indicate some changes were decided:
>
> danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
> setting compileStatic by default via sys…
> danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
> checking and compilation fail when multiple …
> danielsun1106 committed 14 hours ago : Simplify finding generics
> implementation class
>
> However, the meta-concern by Cedric was not addressed it seems. Why is
> anyone directly working on the master branch of groovy?
> Is there a technical reason for this, rather than using feature
> branches, code reviews, and merge approvals?
> Or is it just that nobody would have time to review in a timely
> fashion anyway, so it's either that or zero progress?
>
>
> On Tue, May 8, 2018 at 7:43 AM, MG  wrote:
> > On 07.05.2018 17:54, Cédric Champeau wrote:
> >>
> >> I'd typically very much prefer a custom file extension for example.
> >
> >
> > That would be my preferred way to give anyone a simple mean to choose
> static
> > compilation as the default for a Groovy file. Afair the counter argument
> > was, that Groovy compiles any file with any extension in dynamic mode by
> > default, so this might be a breaking change if someone has used the
> picked
> > extension for his files. Groovy 3.0 might be the right spot to introduce
> > something like this, since there will be breaking changes anyway...
> >
> >> That said, since I'm not contributing code anymore (my last contribution
> >> was rewriting most of the build, which I hope was helpful),
> >
> >
> > Any improvement/speedup of the Gradle build was _definitely_ appreciated
> :-)
> >
> >> I'm happy to step down and let you work as you wish.
> >
> >
> > This is tricky: One cannot agree with just any direction someone who
> invests
> > the time to advance Groovy wants to take it too, that would be taking
> > Doocracy too far, imho, and might lead to a Groovy which is much worse
> than
> > it could be.
> > In this particular case I am torn: I think we could definitely live with
> the
> > system property, I don't feel there is a large probability that it will
> > break anything. On the other hand, using the existing mechanism, or
> > introducing a static compilation source file extension, or a compiler
> switch
> > seem to me to be the better choices - but maybe Daniel can explain why he
> > went with the property approach ?-)
> >
> > Cheers,
> > mg
> >
> >
> >
>

Re: What the... static compile by default

[Mario Garcia]

Remko Could you add a link to Gitbox ?

El vie., 11 may. 2018 a las 17:52, Remko Popma (<remko.po...@gmail.com>)
escribió:

> Over at Log4j we just decided to migrate from git-wip-us to gitbox
> <http://mail-archives.apache.org/mod_mbox/logging-dev/201804.mbox/%3CCACmp6komnUBd-ug7durT7PoSAzgRzBy%2BpmGgWM_7BkMeaj6ksw%40mail.gmail.com%3E>
> .
>
> Using gitbox will allow our projects to integrate better with GitHub
>> including the ability to merge PRs directly from the site and the ability
>> to push commits to GitHub and have them be automatically mirrored back to
>> Apache.
>
>
> This may be interesting for Groovy also.
> We haven't made the move yet so I can't give you feedback from first-hand
> experience.
>
> Remko
>
>
> On Sat, May 12, 2018 at 12:32 AM, Mario Garcia <mario.g...@gmail.com>
> wrote:
>
>> *About Static Compilation changes:*
>>
>> I've used the way it's documented in the official documentation, and I
>> agree with Cedric, I don't like having a system property. I see more
>> benefits using the compiler configuration file:
>>
>>- Configuration is more fine grained (apply to all, apply to some
>>classes, apply to some packages...)
>>- All compilation configuration can be found in one place. Having
>>more than one place to do this could be error prone, and harder to 
>> maintain.
>>- System properties are normally used when the process should vary
>>depending on the environment. In this case, I'm wondering why I would want
>>to compile my code statically in one environment but dynamically in
>>another. Maybe there is a case for that, but to me is weird.
>>
>> *About Daniel response:*
>>
>> I'm so sad to hear that Daniel. In the past few years I've been hearing
>> only amazing things coming from your contributions.  Like someone has
>> mentioned, Groovy 3 wouldn't be the same without you. I really hope you
>> could reconsider your decision and keep contributing to Groovy.
>>
>> *About doing commits on master:*
>>
>> Reading the "Contributing code" section, at groovy-lang.org it seems
>> everybody should be creating a local branch and to a MR afterwards over the
>> remote version of that local branch. So  (again, reading the
>> documentation)  nobody should be adding commits to master directly.
>>
>> I think merge requests are essential. I'm reading Jochen is saying that
>> this is not very straight forward with Github. Could anyone please explain
>> why ? Knowing the pains may help finding the solution.
>>
>> My two cents
>> Mario
>>
>> El vie., 11 may. 2018 3:42, Thibault Kruse <tibokr...@googlemail.com>
>> escribió:
>>
>>> It seems a bit weird to leave this thread dangling after the dramatic
>>> entry scene.
>>>
>>> The activity on master branch seems to indicate some changes were
>>> decided:
>>>
>>> danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
>>> setting compileStatic by default via sys…
>>> danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
>>> checking and compilation fail when multiple …
>>> danielsun1106 committed 14 hours ago : Simplify finding generics
>>> implementation class
>>>
>>> However, the meta-concern by Cedric was not addressed it seems. Why is
>>> anyone directly working on the master branch of groovy?
>>> Is there a technical reason for this, rather than using feature
>>> branches, code reviews, and merge approvals?
>>> Or is it just that nobody would have time to review in a timely
>>> fashion anyway, so it's either that or zero progress?
>>>
>>>
>>> On Tue, May 8, 2018 at 7:43 AM, MG <mg...@arscreat.com> wrote:
>>> > On 07.05.2018 17:54, Cédric Champeau wrote:
>>> >>
>>> >> I'd typically very much prefer a custom file extension for example.
>>> >
>>> >
>>> > That would be my preferred way to give anyone a simple mean to choose
>>> static
>>> > compilation as the default for a Groovy file. Afair the counter
>>> argument
>>> > was, that Groovy compiles any file with any extension in dynamic mode
>>> by
>>> > default, so this might be a breaking change if someone has used the
>>> picked
>>> > extension for his files. Groovy 3.0 might be the right spot to
>>> introduce
>>> > something like this, since there will be breaking changes anyway...
>>> >
>>> >> Tha

Re: Java object conversion using ConfigSlurper

[Mario Garcia]

Hi, good work :)

It seems a nice feature, but I'm wondering why having two different methods
doing the same ? asType and getAs.

   - I think is always better to avoid having two methods doing the same,
   specially when asType can be called both directly or via sugar syntax.
   - I also think the use case fits asType perfectly, as it's mentioned in
   its Groovydoc entry: "Converts a given object to a type"

IMHO I would stick only to asType.

Mario

El mar., 15 may. 2018 a las 9:36, Daniel.Sun () escribió:

> I think it is nice for me :-)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Upcoming releases

[Mario Garcia]

That's good News :)

2018-02-06 8:19 GMT+01:00 Paul King :

>
> I am planning to prepare a 2.5.0-beta-3 release towards the end of this
> week and 2.4.14 not long after. Now's a good time to let us know if there
> is something critical you need for those releases.
>
> I am expecting 2.5.0-beta-3 to be the last beta for 2.5.0 and while there
> are a couple of things we are still planning to finish for 2.5.0, I am
> expecting the next release to kick off the RC release(s), so a final
> release shouldn't be too far away!
>
> Thanks, Paul.
>
>

Re: DGM for first or default

[Mario Garcia]

Eric you can use `find`:

list.find() ?: defaultValue

The method find with no arguments takes the first element, and if the
collection is empty or null it will return null and you won't get an
IndexOutOfBounds

Regards
Mario

El jue., 18 oct. 2018 a las 19:32, Milles, Eric (TR Technology & Ops) (<
eric.mil...@thomsonreuters.com>) escribió:

> Is it still valuable to have DGMs -- whether named "first()" or
> "firstOrDefault()" or whatever?  Content assist does not propose "list ?
> list.first() : defaultValue".  I suppose I'd need to create a code template
> to get that proposal in the IDE.
>
>
> Are there any other small idioms like this that anyone has added as a
> template to improve the editing experience?
> --
> *From:* Milles, Eric (TR Technology & Ops)
> *Sent:* Thursday, October 18, 2018 12:19:42 PM
> *To:* dev@groovy.apache.org
> *Subject:* Re: DGM for first or default
>
>
> "list?.first() ?: defaultValue" is not the equivalent.  If the collection
> is empty, first() throws an IndexOutOfBoundsException is thrown.  That's
> why I'm asking if there is a simple equivalent.  I suppose this is the
> equivalent now that I think about it:
>
>
> list ? list.first() : defaultValue
>
>
> --
> *From:* ocs@ocs 
> *Sent:* Thursday, October 18, 2018 12:07 PM
> *To:* dev@groovy.apache.org
> *Subject:* Re: DGM for first or default
>
> Myself, I am not a huge fan of adding not-often-needed functionalities
> (and actually would add almost none of those discussed lately);
> nevertheless...
>
> On 18 Oct 2018, at 6:48 PM, Paolo Di Tommaso 
> wrote:
>
> -1, it can be easily done as:
> list.first() ?: defaultValue
>
>
> ... this won't work in case the first object is a Groovy False (e.g., an
> empty string, or a plethora of others).
>
> All the best,
> OC
>
>
>
> p
>
> On Thu, Oct 18, 2018 at 6:45 PM Daniel.Sun  wrote:
>
> +0 from me.
> P.S. we should add similar DGM for `last` too?
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> 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
> 
>
>
>

Re: DGM for first or default

[Mario Garcia]

Good point OC:

[0,'',[],[:]].find()?:'not quite what you wanted here'
[0,1,2].find()?:'nor in this case'

The more I think on this the more I think is an interesting topic. I fully
understand your frustration with first(), but apart from the example with
Cocoa you mentioned, looking in the JVM it turns out there're plenty of
examples of language collections behaving that way:

In scala the head of an empty list does throw an exception
---
scala> var empty = List[Int]()
empty: List[Int] = List()

scala> empty.head
java.util.NoSuchElementException: head of empty list
  at scala.collection.immutable.Nil$.head(List.scala:426)
  at scala.collection.immutable.Nil$.head(List.scala:423)
  ... 28 elided

scala>
-

and so does kotlin when calling to first()
--
Welcome to Kotlin version 1.2.71 (JRE 1.8.0_171-b11)
Type :help for help, :quit for quit
>>> val num: List = listOf()
>>> num.first()
java.util.NoSuchElementException: List is empty.
at
kotlin.collections.CollectionsKt___CollectionsKt.first(_Collections.kt:184)
>>>
-
in Kotlin they have firstOrNull(), but I haven't found any overloaded
function with a default value. They also have "find", but it's not possible
to call it without parameter

However Clojure returns null whether:

   - The first element was nil
   - The list was empty
   - Or the list was nil


user=> (def a nil)
#'user/a
user=> a
nil
user=> (first a)
nil
user=> (def a '(nil))
#'user/a
user=> a
(nil)
user=> (first a)
nil
user=> (def a '())
#'user/a
user=> a
()
user=> (first a)
nil
user=>
---

BTW I forgot to mention that Groovy 3 will have safe indexing meaning an
expression like the following:

   - will return the first element of a non empty list which I guess it
   will be the Kotlin firstOrNull() equivalent
   - or null if the list was null or empty

-
// trying to get first element from null list
nullList?[0] ==> null

// trying to get an inexistent element from a non empty list (but this is
not new, this is how a non empty list indexing works in Groovy)
nonNullList?[] => null
--

Outside the JVM, Haskell, when asking for the head of an empty list, throws
an exception (There is an explanation in stackoverflow which I'm afraid I
don't understand). So in the end Groovy's first() seems not to be the
exception among other modern languages out there.

Another point of view, could be thinking about returning null consistently.
Lets say a list returns null using first():

   - Does it mean the first element is a null value or is an empty list and
   that's why is giving me a null value ?
   - What if null is a valid value, with some meaning in my process ? With
   that context a method like firstOrNull() (even first(defaultValue) with a
   null list) could be considered ambiguous.

My guess is that in the case of languages throwing an exception using
first() on an empty list, when they designed the language collections they
didn't have any other way to express that kind of semantics. But this is
just a lucky guess. I'm probably wrong. I only can think of pattern
matching as a complete solution, where the terminal result in the case of
an empty or null list, is a default value different than any of the
elements of the expected result set ?

I apologize in advance for the lengthy e-mail, but it seemed interesting to
think why first() was designed like that, not only in Groovy, but in some
other languages as well.
Mario

El jue., 18 oct. 2018 a las 20:27, Milles, Eric (TR Technology & Ops) (<
eric.mil...@thomsonreuters.com>) escribió:

> I think first() exists so there is a semantic pair for functional
> programming: first()/head() and tail()  or init() and last()
>
> --
> *From:* ocs@ocs 
> *Sent:* Thursday, October 18, 2018 1:20 PM
> *To:* dev@groovy.apache.org
> *Subject:* Re: DGM for first or default
>
> Well I thought *first* is smart enough to return *null* for an empty
> list, same as my *firstObject* in Cocoa does. If it throws, what's on
> earth point of having the thing at all? In that case it can be replaced by
> *list[0]* without any drawback at all.
>
> All the best,
> OC
>
> On 18 Oct 2018, at 7:19 PM, Milles, Eric (TR Technology & Ops) <
> eric.mil...@thomsonreuters.com> wrote:
>
> "list?.first() ?: defaultValue" is not the equivalent.  If the collection
> is empty, first() throws an IndexOutOfBoundsException is thrown.  That's
> why I'm asking if there is a simple equivalent.  I suppose this is the
> equivalent now that I think about it:
>
> list ? list.first() : defaultValue
>
>
> --
> *From:* ocs@ocs 
> *Sent:* Thursday, October 18, 2018 12:07 PM
> *To:* dev@groovy.apache.org
> *Subject:* Re: DGM for first or default
>
> Myself, I am not a huge fan of adding not-often-needed functionalities
> (and actually would add almost none of those discussed lately);
> nevertheless...
>
> On 18 Oct 2018, at 

Re: groovy git commit: Add missing concat methods of tuples

[Mario Garcia]

Apparently the actual Tuple implementation in main branch is creating new
tuples when doing tuple.concat(tuple) (not all but most of), so I guess is
just a matter of making sure what a Tuple is in Groovy. Two options:

   - (1) A tuple is a fixed-length container that can hold any values, but
   cannot be modified (it is immutable) (Taken from Julia Lang)
   - (2) A tuple is a list of N typed objects (Taken from Groovydoc)

If (1) it doesn't matter the method name because it's clear to me by its
definition that a Tuple is always immutable no matter the method called.
If (2) a list in Groovy can be modified, so, maybe method names are
important as MG is mentioning

Once said that, I prefer the immutable version of tuples as value
containers, and I'd vote for changing the Groovydoc definition and enforce
immutability to avoid ambiguity.
Mario

El lun., 26 nov. 2018 a las 20:41, MG () escribió:

> My 2 Cents: I supply two seperate methods in that case, e.g.:
>
> 1) Columns#sort(...) ... sort the List collection held by the
> Columns class (same name for zero parameters case)
>
> 2a) Columns#getSorted() ... create new Columns instance with its
> List sorted
> 2b) Columns#sorted(...) ... create new Columns instance with its
> List sorted (parameter case)
>
> Method names should clearly express what the method does (to me the
> imperative "sort", compared  with the adjective state "(return something
> which is) sorted" does that) - nothing worse than you thinking you get a
> new instance, and end up modifying the original instance, or thinking you
> are working in place, when in fact you are creating new objects all the
> time...
>
> Here:
>
> Tuple#concat(Tuple)  ... modify existing
> Tuple#concatenated(Tuple) ... return new instance
>
> Cheers,
> mg
>
>
> Am 26.11.2018 um 19:29 schrieb Mario Garcia:
>
> I'd do it if the intention is to enforce immutability of tuples, like
> "...any operation applied to a tuple should result in a new tuple"
>
> Regards
> Mario
>
> El lun., 26 nov. 2018 15:44, Paul King 
> escribió:
>
>> On Tue, Nov 27, 2018 at 12:34 AM  wrote:
>> >
>> > Repository: groovy
>> > Updated Branches:
>> >   refs/heads/master aa372c484 -> b6933c7ef
>> >
>> >
>> > Add missing concat methods of tuples
>> [SNIP]
>> >  /**
>> >   * Concatenate a tuple to this tuple.
>> >   */
>> > +public final Tuple1 concat(Tuple0 tuple) {
>> > +return new Tuple1<>(v1);
>> > +}
>> [SNIP]
>>
>> Returning a new tuple is important? Vs returning this?
>>
>> Cheers, Paul.
>>
>
>

Re: groovy git commit: Add missing concat methods of tuples

[Mario Garcia]

I'd do it if the intention is to enforce immutability of tuples, like
"...any operation applied to a tuple should result in a new tuple"

Regards
Mario

El lun., 26 nov. 2018 15:44, Paul King  escribió:

> On Tue, Nov 27, 2018 at 12:34 AM  wrote:
> >
> > Repository: groovy
> > Updated Branches:
> >   refs/heads/master aa372c484 -> b6933c7ef
> >
> >
> > Add missing concat methods of tuples
> [SNIP]
> >  /**
> >   * Concatenate a tuple to this tuple.
> >   */
> > +public final Tuple1 concat(Tuple0 tuple) {
> > +return new Tuple1<>(v1);
> > +}
> [SNIP]
>
> Returning a new tuple is important? Vs returning this?
>
> Cheers, Paul.
>

Re: requesting your advice on picocli modules

[Mario Garcia]

+ 1 picoli-groovy.jar

Great project BTW!

El jue., 30 may. 2019 a las 14:51, Remko Popma ()
escribió:

> Hi,
>
> I maintain the picocli library for creating command line applications in
> Groovy, Java, and other JVM languages.
> I have a question for the Groovy community (both users and developers):
>
> Currently, the picocli main jar contains both the core `picocli` package
> and a `picocli.groovy` package with classes that make it easy for Groovy
> scripts to use picocli annotations. I'm considering splitting up this jar.
>
> In an upcoming major release of the library I plan to provide a Java 9
> JPMS modular jar containing just the core `picocli` package and
> additionally a `module-info.class` to make this jar a full-fledged Java
> module.
>
> The question is what to do with the picocli.groovy package. I see two
> options:
> 1) have a `picocli-groovy` jar containing _only_ the picocli.groovy
> package - this jar would require (have a dependency on) the core picocli
> jar (the JPMS modular jar). Ideally this `picocli-groovy` jar would also be
> a JPMS module, but not sure if that's possible.
> 2) have a `picocli-legacy?` (name TBD) jar containing both the core
> picocli package and the picocli.groovy package - similar to the current
> picocli-3.9.x jar
>
> I believe the first option may be cleanest. Scripts would need to change
> their grape module from @Grab('info.picocli:picocli:$version') to
> @Grab('info.picocli:picocli-groovy:4.0.0') and that would bring in the
> transitive dependency on 'info.picocli:picocli:4.0.0', if my understanding
> is correct.
>
> Can anyone see any drawbacks with this approach?
> Would there be any point in additionally providing a `picocli-legacy`
> (name TBD) jar containing both the core picocli package and the
> picocli.groovy package, similar to the current picocli-3.9.x jar?
>
> On a side-note, has anyone had any issues with putting the
> `module-info.class` in the root of the modular jar versus putting it in
> META-INF/versions/9/ in the jar?
> Some people  use
> META-INF/versions/9/ as a way to (hopefully) avoid issues with older tools
> unable to cope with the `module-info.class`. Does anyone have any
> experience with this?
>
> Remko
>
>

Re: [PROPOSAL]Support conditional return

[Mario Garcia]

Hi all:

Very interesting topic.

The first idea sprang to mind was the PMD rule in Java saying you should
have more than one exit point in your methods (
https://pmd.github.io/latest/pmd_rules_java_codestyle.html#onlyonereturn).
But the reality is that sometimes (more often than not) we are forced to
break that rule. In fact sometimes we could even argue that breaking that
rule makes the code clearer (e.g
https://medium.com/ncr-edinburgh/early-exit-c86d5f0698ba)

Although my initial reaction was to be against the proposal, however after
doing some coding, I've found that neither elvis nor ternary operators
makes it easier nor clearer. Here's why I think so. Taking Daniel's example:

```
def m() {
   def a = callA()
   if (null != a) return a

   def b = callB()
   if (b > 10) return b

   def c = callC()
   if (null != c && c < 10) return c

   LOGGER.debug('the default value will be returned')

   return defaultValue
}
```
The shortest elvis operator approach I could think of was:
```
def m2() {
   return callA()
   ?: callB().with { it > 10 ? it : null }
   ?: callC().with { null != it && it <10 ? it : null }
}
```

which to be honest, is ugly to read, whereas Daniel's proposal is just:

```
def m() {
   return? callA()
   return(r -> r > 10) callB()
   return(r -> null != r && r < 10) callC()
   return defaultValue
}
```

Once said that, I would say this conditional return could be useful only
when there are more than two exit points, otherwise ternary or elvis
operators may be good enough.

So, bottom line, I kinda agree to add conditional return, but I'm not sure
about the final syntax:

```
return(r -> r > 10) callB()
return callB() [r -> r > 10]
return callB() if (r -> r > 10)
```

Between the three I the one that I like the most is the third one:

```
return callB() if (r -> r > 10)
```

You can read it in plain english as "return this if this condition
happens".

Apart from Daniel's use case, using this option could open the
possibility to use, not only a closure or lambda expression, but also a
plain expression. A nice side effect could be that something like the
following code:

```
def doSomething(int a) {
  return callB() if a > 6
  return callC() if a > 5
  return callD() if a > 4
}
```

turns out to be a shorter (and in my opinion nicest) way of switch case
(when you want every branch to return something):

```
def doSomething(int a) {
  switch (a) {
 case { it > 6 }: return callB()
 case { it > 5 }: return callC()
 case { it > 4 }: return callD()
  }
}
```

Well, bottom line, I'm +1 Daniel's proposal because I've seen some cases
where this conditional return could make the code clearer.

Cheers
Mario

El sáb., 25 jul. 2020 a las 23:55, Paolo Di Tommaso (<
paolo.ditomm...@gmail.com>) escribió:

> It's not much easier a conditional expression (or even the elvis
> operator)?
>
> ```
> def m() {
> def r = callSomeMethod()
> return r != null ? r : theDefaultResult
> }
> ```
>
>
> On Sat, Jul 25, 2020 at 8:56 PM Daniel Sun  wrote:
>
>> Hi all,
>>
>>  We always have to check the returning value, if it match some
>> condition, return it. How about simplifying it? Let's see an example:
>>
>> ```
>> def m() {
>> def r = callSomeMethod()
>> if (null != r) return r
>>
>> return theDefaultResult
>> }
>> ```
>>
>> How about simplifying the above code as follows:
>> ```
>> def m() {
>> return? callSomeMethod()
>> return theDefaultResult
>> }
>> ```
>>
>> Futhermore, we could make the conditional return more general:
>> ```
>> def m() {
>> return(r -> r != null) callSomeMethod() // we could do more checking,
>> e.g. r > 10
>> return theDefaultResult
>> }
>> ```
>>
>> Any thoughts?
>>
>> Cheers,
>> Daniel Sun
>>
>

Re: Proposal handling of potential variable declarations for expressions starting with an underscore or dollar

[Mario Garcia]

If it helps, I've seen some programmers with python background using the
underscore in Groovy for method declaration. It seems they use the
convention of the underscore prefix to note these methods aren't for public
consumption.

El jue, 11 feb 2021 a las 9:49, Paul King ()
escribió:

>
> Hi folks,
>
> I would be interested in any thoughts about the following issue:
>
> https://issues.apache.org/jira/browse/GROOVY-9936
>
> TL;DR There is an edge case where Groovy 3 (Parrot) behavior now differs
> from the old parser. Even though an argument could be made either way as to
> which behavior is better, I propose we align with the old parser.
>
> Proposed PR:
>
> https://github.com/apache/groovy/pull/1485
>
> Let me know your thoughts.
>
> Thanks, Paul.
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-5064115683895307916_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: [DISCUSS] Some potential additional system properties/CompilerConfiguration flags for Groovy 4

[Mario Garcia]

Hi:

Here are my thoughts. Maybe I'm wrong but, if somebody is familiar with
JDK17 sealed classes, I don't think that person would expect that using
sealed syntax with JDK8 is going to output a JDK17 sealed class. I would
add it to the documentation and that's it.

To me seems that implementing such scenario of compiler configuration is
going to be done for the sake of part of the 1/3 of the potential users:

   - I would like to use sealed-classes -> use JDK17
   - I love Groovy and I'd like to use sealed classes -> Use Groovy 4 and
   JDK 17
   - I love Groovy but I'm stuck in JDK8 OR I love Java and I'd like to use
   sealed classes but again stuck in JDK8 -> Use Groovy 4 and be aware that,
   although it looks like sealed classes, you're not using JDK17, so it
   won't be the JDK17 sealed class

Anyway, I would wait until this is really a real concern rather than a
premature optimization and I would use that time and effort in other parts
of the language. You already mentioned it, I also think Codenarc could be a
good fit for this.

My two cents

El mar, 21 sept 2021 a las 9:41, Paul King () escribió:

>
> Hi folks,
>
> [A bit of a long winded explanation but hopefully you will bear with me.]
>
> For recent features like sealed classes and records*, we are moving
> towards implementations which support the feature natively (as per Java)
> when compiled with a suitable target bytecode version, and fall back to
> some alternate mechanism on older JDK versions. E.g. native sealed classes
> vs a @Sealed annotation. For sealed classes there are flags
> in CompilerConfiguration (and corresponding system properties) to give
> better control, e.g. do you still want the annotations even on a native
> sealed class. Feedback on the existing implementation is as always welcome
> but that is distinct from what I am asking here.
>
> Do folks think an additional flag would be useful that failed compilation
> if the native option wasn't enabled?
>
> Here is an example to spell out the idea. The idea is that if I have:
>
> sealed class Shape { ... }
> final class Triangle extends Shape { ... }
> ...
>
> And then, if I compile with target bytecode at JDK17 I will get a sealed
> class (for Shape) as expected in the Java world but just one annotated
> with @Sealed if I use for instance JDK8. The target version is detected and
> used to switch between the two potential outcomes with already some flags
> to control the behavior a little. I wonder whether folks familiar with Java
> will be surprised that they use the `sealed` keyword but don't really get a
> sealed class and they are hoping to use the class as is with Java.
>
> It seems we have three options:
> (1) Leave as is. Our documentation explains the fallback scenarios, so
> users should familiarise themselves with it!
> (2) Provide an additional system property/flag/CompilerConfig setting
> which users could turn on and if the target bytecode version doesn't meet
> the required level for native support it would fail. The flag would be opt
> in, i.e. our existing best implementation based on version is the default
> but the flag would give a stricter option. With the flag set, if you
> compile my "sealed class" code on an old JDK it won't compile since I
> really meant to get a sealed class.
> (3) Leave this up to the next gen of CodeNarc Groovy 4 rules (not sure we
> have ever had version specific ones like this before).
>
> This example is around sealed classes but there will be similar concerns
> for records. Thoughts?
>
> * PR pending
>
> Cheers, Paul.
>
>

Re: Welcome Remko Popma to the Apache Groovy PMC!

[Mario Garcia]

Good news! Congratulations Remko!

El mié, 13 jul 2022 a las 8:59, Paul King () escribió:

> Remko Popma has been voted as an additional member to the Apache
> Groovy PMC. Congratulations Remko!
>
> Remko has been a committer for some time, and was the main contributor
> for the groovy-cli-picocli module. He is also on the PMC of Apache
> Logging.
>
> Cheers, Paul.
> On behalf of the Apache Groovy PMC.
>

Re: Possible additional DGM collectEntries variants

[Mario Garcia]

+1.

Hi all. For me it makes more sense to have a specific method for that
(collectEntriesWith, collectEntriesWithKey...) than overloading
collectEntries and forcing me to introduce the java.util.function api just
for so little.

El lun, 19 dic 2022 a las 12:23, Paul King () escribió:

>
> Hi folks,
>
> @mrhaki who many of you may know as the author of "Groovy Goodness" also
> covers other topics and recently covered Kotlin's associate method:
>
>
> https://blog.jdriven.com/2022/12/kotlin-kandy-transform-items-in-a-collection-to-a-map-with-associate/
>
> Groovy addresses this use case fairly well using collectEntries, e.g.:
>
> var languages = ['Kotlin', 'Groovy', 'Java', 'Clojure']
> assert languages.collectEntries{ [it.toLowerCase(), it.size()] } ==
> [kotlin:6, groovy:6, java:4, clojure:7]
> assert languages.collectEntries{ [it.toLowerCase(), it] } ==
> [kotlin:'Kotlin', groovy:'Groovy', java:'Java', clojure:'Clojure']
> assert languages.collectEntries(Scala:5){ [it, it.size()] } ==
> [Scala:5, Kotlin:6, Groovy:6, Java:4, Clojure:7]
>
> But we don't have exact equivalents to associateWith and associateBy. The
> collectEntries variants handle all the cases but there is some simplicity
> that would come with additional equivalent variants, e.g.:
>
> // "collectEntriesWith" could be just "collectEntries" if we want
> assert languages.collectEntriesWith(String::toLowerCase, String::size) ==
> [kotlin:6, groovy:6, java:4, clojure:7]
> // equivalent of associateBy
> assert languages.collectEntriesWithKey(String::toLowerCase) ==
> [kotlin:'Kotlin', groovy:'Groovy', java:'Java', clojure:'Clojure']
> // equivalent of associateWith
> assert languages.collectEntriesWithValue(String::size) ==
> [Kotlin:6, Groovy:6, Java:4, Clojure:7]
>
> The method names are just suggestions at this point.
>
> Thoughts?
>
> Cheers, Paul.
>
>
>
>

Re: Fix remainder operator for BigInteger (GROOVY-10800)

[Mario Garcia]

The idea of fixing inconsistencies is great. I also like the idea of giving
a mid-term solution for those using the mod operator "incorrectly". But I'm
not sure about opening the door for precisely overloading operators with
different names than the ones specified by default, that seems to be just
the opposite this proposal is for, to avoid different people to approach
the same operator differently. Apart from that, I think that the new
feature has to be maintained as well, and it wasn't born as a feature
Groovy developers wanted but a workaround for something that had to be
fixed.

I would add the @OperationRename renaming it as @ModRenamed (or something
alike) as a transitional workaround for those using mod the old way.

My two cents
Mario

El jue, 23 mar 2023 a las 2:44, Paul King () escribió:

> Hi folks,
>
> It has been a while but I finally got back around to this issue.
>
> As a reminder, this issue is about using "mod" as the name of the method
> for the "%" operator. Both remainder and mod are the same for positive
> numbers, and we are guilty in informal contexts of sometimes conflating the
> names, but they differ for negative numbers. This caused a difference (only
> for negative numbers) for BigIntegers. In the earlier email, I was going to
> look at "patches" which would allow us to keep "mod" as the operator name.
> I tried numerous "fixes" but they all seemed like patches on top of patches
> rather than a clean solution. So, instead I went with the solution (which I
> previously described as "somewhat intrusive") of renaming the name of the
> operator method to "remainder". This makes it a breaking change for Groovy
> 5 (for -ve numbers and also anyone using the "mod" method name relying on
> DSL-like code) but arrives at a much cleaner solution.
>
> I have created the following PR here:
>
> https://github.com/apache/groovy/pull/1878
>
> To minimise the impact on existing users, I added a new AST
> transform, @OperationRename, which could be used by anyone affected by the
> change when writing DSL-like code using "mod". This also has the advantage
> of giving another option when wanting to use operator overloading with
> existing libraries that might not use the method names Groovy uses, e.g.
> subtract/add/times instead of minus/plus/multiply. We could also look at
> some metaclass tweaking so that the runtime looks for "mod" as a fallback
> for "remainder" before jumping to method missing but I'd probably do that
> as a second pass only if there is sufficient interest.
>
> Thoughts?
>
> Cheers, Paul.
>
>
> On Fri, Oct 28, 2022 at 9:34 PM Paul King  wrote:
>
>> Hi folks,
>>
>> As part of fixing GROOVY-10800, I was planning to make the behavior
>> for the "%" operator for BigInteger be consistent with our other data
>> types (and with Java).
>>
>> Basically, there is a distinction between "remainder" and "modulo" for
>> negative numbers.
>> For the expression "numerator op divisor", they will be the same for
>> positive numbers but for negative numbers, "remainder" will return a
>> negative number for a negative numerator while "modulo" will always
>> return a number "0 <= result < divisor". You can get one from the
>> other by adding the divisor to a negative result from "remainder".
>>
>> What is sometimes a little confusing is that the "remainder" operator
>> (%) is often informally referred to as the "mod" operator (since they
>> are the same for positives). Indeed, we use "mod" as the name of the
>> method to use for operator overloading purposes.
>>
>> Currently the behavior is:
>>
>> def nums = [-10, -10L, -10f, -10d, -10G, -10.0G]
>> assert nums.collect{ it % 3 } == [-1, -1, -1f, -1d, 2G, -1.0G]
>>
>> (Note: The BigDecimal result relies on GROOVY-10786, so currently only
>> in master.)
>>
>> Changing the behavior is easy (albeit breaking for negatives) but
>> there is a knock on consequence. Since we use "mod" as our method for
>> operator overloading, the BigInteger "mod" method is then no longer
>> available.
>>
>> For Groovy 5, we could go and rename our operator overloading method
>> from "mod" to "remainder" or some such but it is quite an intrusive
>> change.
>>
>> There is a workaround which we could document:
>>
>> def negTen = -10G
>> assert 2G == negTen.modPow(1, 3)
>>
>> And/or we could provide a "modulo" extension method on BigInteger to
>> allow:
>>
>> assert 2G == negTen.modulo(3)
>>
>> This last approach was what I was thinking of doing.
>>
>> Thoughts?
>>
>> Cheers, Paul.
>>
>

Re: Fix remainder operator for BigInteger (GROOVY-10800)

[Mario Garcia]

On the other hand, I've been dealing with that in the past, and I agree
that it would have been very helpful having @OperationRename, at least for
prototyping. What I did in the past, was to create an extension for the
specific library in order to be able to use operators everywhere in the
project's code, not just a part of it, so that's where my bias comes from.
I didn't see myself using it contained in small pieces of code but in an
entire codebase.

However I guess using @OperationRename, for example in a Groovy script,
doing some maths using a third party library (not following Groovy
operators conventions), makes perfect sense.

Thinking in a bigger project, If I've got it right, if I had a class where
I would like to contain all mathematical operations, I could annotate the
class with @OperationRename and everything would go ok unless I use
different libraries with different method names for the same operator. But
then I could extract what I needed in different methods. Sounds reasonable.

Bottom line, changed my mind (and of course forget about what I said
about @ModXXX
annotation)
Cheers, Mario

El jue, 23 mar 2023 a las 13:28, Paul King () escribió:

> We could go with an AST transform specifically for fixing "mod" but I
> don't think it is accurate to say the feature isn't wanted in its own right.
> We already do the same kind of rename using runtime metaprogramming all
> the time, we would now just have a way to do it using compile-time
> metaprogramming as well.
>
> Some examples which spring to mind:
> Groovy's operators: plus, minus, multiply, power
> Apache Commons Math matrices: add, subtract, multiply, power
> EJML matrices: plus, minus, mult, n/a
> Nd4j matrices: add, sub, mmul, n/a
> ojAlgo matrices: add, subtract, multiply, power
> Commons numbers fractions: add, subtract, multiply, pow
> Commons numbers complex: add, subtract, multiply, pow
>
> Cheers, Paul.
>
>
> On Thu, Mar 23, 2023 at 6:21 PM Mario Garcia  wrote:
>
>> The idea of fixing inconsistencies is great. I also like the idea of
>> giving a mid-term solution for those using the mod operator "incorrectly".
>> But I'm not sure about opening the door for precisely overloading operators
>> with different names than the ones specified by default, that seems to be
>> just the opposite this proposal is for, to avoid different people to
>> approach the same operator differently. Apart from that, I think that the
>> new feature has to be maintained as well, and it wasn't born as a feature
>> Groovy developers wanted but a workaround for something that had to be
>> fixed.
>>
>> I would add the @OperationRename renaming it as @ModRenamed (or something
>> alike) as a transitional workaround for those using mod the old way.
>>
>> My two cents
>> Mario
>>
>> El jue, 23 mar 2023 a las 2:44, Paul King ()
>> escribió:
>>
>>> Hi folks,
>>>
>>> It has been a while but I finally got back around to this issue.
>>>
>>> As a reminder, this issue is about using "mod" as the name of the method
>>> for the "%" operator. Both remainder and mod are the same for positive
>>> numbers, and we are guilty in informal contexts of sometimes conflating the
>>> names, but they differ for negative numbers. This caused a difference (only
>>> for negative numbers) for BigIntegers. In the earlier email, I was going to
>>> look at "patches" which would allow us to keep "mod" as the operator name.
>>> I tried numerous "fixes" but they all seemed like patches on top of patches
>>> rather than a clean solution. So, instead I went with the solution (which I
>>> previously described as "somewhat intrusive") of renaming the name of the
>>> operator method to "remainder". This makes it a breaking change for Groovy
>>> 5 (for -ve numbers and also anyone using the "mod" method name relying on
>>> DSL-like code) but arrives at a much cleaner solution.
>>>
>>> I have created the following PR here:
>>>
>>> https://github.com/apache/groovy/pull/1878
>>>
>>> To minimise the impact on existing users, I added a new AST
>>> transform, @OperationRename, which could be used by anyone affected by the
>>> change when writing DSL-like code using "mod". This also has the advantage
>>> of giving another option when wanting to use operator overloading with
>>> existing libraries that might not use the method names Groovy uses, e.g.
>>> subtract/add/times instead of minus/plus/multiply. We could also look at
>>> some metaclass tweaking so that the runtime looks fo