CompileStatic: Improved method call/property access Java compatibility for Minecraft Forge obfuscation support

, etc. Cheers, mg

break/return/continue support in "Appended Block Closures" finally completed

bend Closure semantics close to breaking point - I realized that support for inlining closures would trivially introduce break/return/continue support - and a bit later I saw that what I had thought about was exactly the way Kotlin does it...). Cheers, mg

Re: Building Groovy

I also agree. The one argument I see for a fat groovy-all, is that it lowers the hurdle of trying Groovy in your project, if you are in a (e.g. secure) environment where you cannot use Maven/Gradle to pull in all dependencies from the internet. On 22.11.2017 20:22, Leonard Brünings wrote: I

Re: Building Groovy

I like groovy-standalone.jar as a name (clearer than "all"). Alas changing names breaks all internet guides/posts/etc preceeding the name change, so one has to be careful with things like this... On 22.11.2017 23:33, Leonard Brünings wrote: If you are doing that then most likely you won't be

Re: Building Groovy

I did download the distribution a few years back, but still added groovy-all to my project, since it is simply more convenient and groovy-all sounds like it is the thing you want. If Groovy is just something you are giving a shot, and you have a lot of things to evaluate, you naturally  want to

Re: Building Groovy

;all", just a point to keep in mind when picking names ... Cheers, Paul. On Thu, Nov 23, 2017 at 8:53 AM, MG wrote: I like groovy-standalone.jar as a name (clearer than "all"). Alas changing names breaks all internet guides/posts/etc preceeding the name

Re: Building Groovy

large companies without access to internet don't use build tools. We have quite evidence of the contrary (they tend to use internal repositories). 2017-11-23 12:08 GMT+01:00 mg : I was thinking the same. Without being all for changing the name, maybe:groovy-single.jargroovy-fat.jargroovy

Re: Building Groovy

tool, and it's also done for you. And I doubt large companies without access to internet don't use build tools. We have quite evidence of the contrary (they tend to use internal repositories). 2017-11-23 12:08 GMT+01:00 mg <mailto:mg...@arscreat.com>>:     I was thinking th

Re: How to find out the names of variables used in a groovy expression

I think he is looking for C# Linq-like support. Support for that was mentioned a few months back.  In the meantime maybe the new macro functionality can help ? Ursprüngliche Nachricht Von: Jesper Steen Møller Datum: 26.11.17 12:32 (GMT+01:00) An: dev@groovy.apache.org Betreff

Re: How to find out the names of variables used in a groovy expression

After the clarification I would also recommend and approach along the line of waiting until the binding actually tries to access an unbound variable and evaluate its value then (since the name of the variables is not actually needed for anything else)... On 26.11.2017 19:47, Marcin Erdmann wro

Re: How to find out the names of variables used in a groovy expression

I use Groovy as a programming, not as a script langage, so I have not done something like this myself, but something along the line of http://groovyconsole.appspot.com/script/112001 should work. On 26.11.2017 19:26, bayareagreg wrote: All right, let me explain why I need this. In my product, we

ORA-01000: maximum open cursors exceeded

appreciated, because right now we are stuck on 2.4.7, Cheers, mg PS: Even though I did not expect the result top be different I gave 2.5.0-beta-2 a try, but ran into multiple bugs (reports upcoming) that prevented my code to get to the schema evolver part.

Re: Is FieldsAndPropertiesStaticCompileTest#testUseGetterFieldAccess really correct?

page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16284807 Cheers, mg On 24.11.2017 01:46, Jochen Theodorou wrote: Hi all, the test is defined as this:     void testUseGetterFieldAccess() {     assertScript '''     class A {     boolean g

Re: Is FieldsAndPropertiesStaticCompileTest#testUseGetterFieldAccess really correct?

Hi Jochen, thanks for the quick reply. Using direct field access (y.@x) leads to the same problem (see Jira). Bye, mg On 09.12.2017 21:23, Jochen Theodorou wrote: On 09.12.2017 17:45, MG wrote: Hi Jochen, did you ever get around to pushing the fix you mentioned ? I just checked if the

Re: Package specific syntax

"this" in this case being bound to ?-)(i.e. what do you mean by "this" - having a package keyword or an annotation ?) Ursprüngliche Nachricht Von: Daniil Ovchinnikov Datum: 13.12.17 23:14 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Package specific syntax This is the

Re: Package specific syntax

Why is a keyword better than an annotation from an IDE developer's perspective (considering Groovy already has tons of annotations which more complex semantics than @PackageScope) ? On 13.12.2017 23:14, Daniil Ovchinnikov wrote: This is the best way from IDE perspective. — Daniil Ovchinniko

Re: Package specific syntax

keyword, due to it supporting parameters to restrict its applicability to e.g. class fields only - so I guess you would have to scan for @PackageScope in any case... Cheers,mg Ursprüngliche Nachricht Von: Daniil Ovchinnikov Datum: 15.12.17 14:13 (GMT+01:00) An: MG Betreff: Re

Re: CC and build revision

/description of things that would need doing to get GPars 2.0 (if it is tied to Groovy 3.0 you might consider syncing the version numbers for psychological reasons - sonehow 2.0 sounds very 2000-ish to me) out of the door, and if it would make sense to post it here ? Cheers,mg

Re: CC and build revision

I agree with Russel, thank you. Apart from the cleanup/streamlining, especially enabling minimal rebuild (cache) is a big step forward :-) Ursprüngliche Nachricht Von: Cédric Champeau Datum: 15.12.17 13:37 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: CC and build revisi

Re: Building Groovy

holds for more projects, I expect it will not go down well with (dynamic) Groovy users... mg On 21.11.2017 17:38, Jochen Theodorou wrote: Am 21.11.2017 um 08:28 schrieb Paul King: The "double" build is because of indy vs non-indy (one wipes out the other) because of some assumptions

Re: Building Groovy

it like a software renderer going up against a GPU...) Cheers, mg On 18.12.2017 15:54, Jochen Theodorou wrote: On 18.12.2017 01:01, MG wrote: Just came across this as an example where using Groovy 2.4.6 invokedynamic seems to have been much slower than the older callsite caching mechanis

Re: Building Groovy

On 19.12.2017 09:37, Cédric Champeau wrote: 2017-12-19 2:21 GMT+01:00 MG <mailto:mg...@arscreat.com>>: Hmmm, I don't know if Paul has some comeback, but to me you make a very convincing point... In that case the best way forward to me seems to be to 1) Ask non-

Re: Building Groovy

project among others, on which one developer could work for some time. And it woud allow companies who use Groovy to expedit development without committing too much... Cheers, mg

Re: GPars progress [was CC and build revision]

Good move, Russell :-) Ursprüngliche Nachricht Von: Russel Winder Datum: 21.12.17 17:59 (GMT+01:00) An: dev@groovy.apache.org Cc: GPars Users , Groovy_Users Betreff: Re: GPars progress [was CC and build revision] I have started a TODO wiki page at https://github.com/GPars/

Re: G-String embedded Closure calling bug?

I have never wanted to embed a Closure obj in a GString, but the behavior is definitely a bit unexpected. I must admit that I feel that Groovy features like being able to iterate over null, or that an empty collection is Groovy-true are more of a problem imho. I have never had any application fo

Re: Building Groovy

But the fact that it is an internal implementation detail does not prohibit technical minded people to be interested in them. Most developers I have met were interested in such things. Most men have e.g. at least some knowledge about the inner workings of their car, even if that are internal imp

Re: Gradle build updates

hat, to not go nuts (and only uses Gradle at the end for the "official build check")... Cheers,mg Ursprüngliche Nachricht Von: Jochen Theodorou Datum: 23.12.17 13:13 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Gradle build updates hi all, is there an easy way t

Re: Gradle build updates

PS: Latest improvements on the Gradle build sound great, of course, not to take anything away from that :-) Ursprüngliche Nachricht Von: mg Datum: 23.12.17 14:43 (GMT+01:00) An: dev@groovy.apache.org Cc: Jochen Theodorou Betreff: Re: Gradle build updates Hi Jochen, when I

Re: Gradle build updates

(PPS: Just to be clear: I did not use the Gradle build from IntelliJ but used the IntelliJ build system) Ursprüngliche Nachricht Von: mg Datum: 23.12.17 15:32 (GMT+01:00) An: dev@groovy.apache.org Cc: Jochen Theodorou Betreff: Re: Gradle build updates PS: Latest

Re: About adding DGM startsWith(String...) and endsWith(String...)

All for adding that: Very helpful, does not break any existing code, should be faster than any regex based solution (and be honest: Who wouldn't wrap the regex solution in a helper method if used more than 2x in the code, using a substring based solution along the way... ?-) ). Ursprüng

Re: About adding DGM startsWith(String...) and endsWith(String...)

All for adding that: Very helpful, does not break any existing code, should be faster than any regex based solution (and be honest: Who wouldn't wrap the regex solution in a helper method if used more than 2x in the code, using a substring based solution along the way... ?-) ). Ursprüng

Re: G-String embedded Closure calling bug?

ok like this: String toDebugString(int indentationLevel = 0, String indentationString = '\t') and implementations are expected to indent the resulting String accordingly, which is very helpful for complex objects which require a multi-line output to make sense of them in a debug log. Wh

Re: [VOTE]Support package scope via `package` keyword

, and introduces the problem that the fine-granularity feature of package scope in Groovy gets overlooked completely, making it a dead feature. Cheers, mg On 31.12.2017 05:50, Nathan Harvey wrote: Perhaps another alternative could be introducing a @Scope annotation to apply the scoping behavior u

Re: [VOTE] Inner-project extension methods

Non-PMC +1, purely from a Groovy user's perspective... On 31.12.2017 04:51, Nathan Harvey wrote: I'm starting a vote to add the ability to declare extension methods within the same project that they are used, removing the requirement to isolate them to a separate/external dependency. More discus

Re: About adding DGM startsWith(String...) and endsWith(String...)

+1 on startsWithAny or startsWithAnyOf (was thinking along the same line after my reply). Better expresses the use and keeps startsWith free to be extended with other arguments in the future. @Offset parameter: I tend to be for offering more functionality - though I must admit I do not see the

toDebugString as a Groovy core concept

Hi all, I have created a jira for my proposed toDebugString Groovy feature: https://issues.apache.org/jira/browse/GROOVY-8431 Cheers, mg

Re: toDebugString as a Groovy core concept

core concept Out of curiosity, you know about the dump() method on Object?How close / different is it from your proposal of toDebugString()?(dump() had that same purpose initially) Guillaume On Wed, Jan 3, 2018 at 6:39 PM, MG wrote: Hi all, I have created a jira for my proposed toDebugString G

Re: Making @Immutable a meta-annotation

Hi Paul, great to make @Immutable more fine granular / flexible :-) what about @ImmutabilityCheckedor@ImmutableCoreinstead of @ImmutableClass ? Cheersmg Ursprüngliche Nachricht Von: Paul King Datum: 11.01.18 08:07 (GMT+01:00) An: dev@groovy.apache.org Betreff: Making @Immutab

Re: About the native-lambda branch

On 13.01.2018 01:00, Nathan Harvey wrote: On the other hand, lambdas are superior for functional programming because they can be differentiated with Java 8's functional type classes quite easily. Could you give an example on what exactly you mean by that, and in what sense you see them as be

Re: Making @Immutable a meta-annotation

nctionality, etc. How about: @ImmutableOnly @PureImmutable @ModificationProtected @Locked @Frozen @Unchangeable @Changeless @InitOnly @InitializeOnly @Constant @Const @NonModifieable @NonChangeable ? mg On 12.01.2018 08:01, Paul King wrote: @ImmutableCore is similar to @ImmutableBase - proba

Re: Making @Immutable a meta-annotation

ty of being immutable ? Something either is immutable, or not (@ImmutableCore also fails in this regard ;-) ). So still would prefer @ImmutableOnly o.s. ... Cheers, mg Ursprüngliche Nachricht Von: Paul King Datum: 13.01.18 13:17 (GMT+01:00) An: MG Betreff: Re: Making

Re: Making @Immutable a meta-annotation

east expresses that this annotation just tags the class as having certain properties, and that this is a general fact, and not only known to developers or compilers in the know... I hope I do not completely miss your point, but this is how it looks to me from what I read :-), Cheers, mg

Re: Making @Immutable a meta-annotation

), that does not mean it is a good choice for the annotation name. But as I said, if you are convinced that one requires the other, this discussion is mute anyway... On 16.01.2018 01:56, Paul King wrote: Explanations below. On Tue, Jan 16, 2018 at 12:56 AM, MG <mailto:mg...@arscreat.com>&g

Re: Making @Immutable a meta-annotation

) different things.) Cheers, mg *Which is always good in my book, plus most people will use @Immutable meta-annotation anyway, plus everyone can create their own meta-annotations from these fine granular annotations (to avoid code clutter) On 17.01.2018 01:48, Paul King wrote: Response inline

Re: Making @Immutable a meta-annotation

m:-)g On 24.01.2018 04:39, Paul King wrote: Okay, I made those changes. There is now a makeImmutable annotation attribute. Still a bunch of tidying up work to do including documentation refinements but any feedback welcome. cheers, Paul. On Sat, Jan 20, 2018 at 10:03 AM, MG <mailto

Re: Add a marker interface to bypass Collections and Maps formatting

f it would perhaps make sense to introduce a more generically named annotation (@AutomatismOverride, @GroovyOverride, @Configuration,...), that would allow overriding/fine-tuning many of Groovy's automatisms through different parameters, to avoid an annotation-explosion over time ? mg On 2

Re: groovy git commit: Increase the possible size of value in GString instance

Hi Daniel, as far as I read Jochen's mail, it was not the rationale that was challenged per se, but the lack of expressing such in the form of a comment in the code... :-) Cheers, mg On 26.01.2018 01:21, Daniel Sun wrote: Hi Jochen, Let's have a look at some norma

Re: About the callable native lambda

call  doesn't exist" weaken the elegance of the whole concept too much ? mg On 31.01.2018 10:00, Jesper Steen Møller wrote: Hi list FYI: This turned into a discussion of the feature itself, on the GitHub commit thread. Basically, I'm proposing changing what "obj(params...

Re: Thread contention on GroovyClassLoader sourceCache

Suggestion: GroovyScriptCompiler o.s., and add comment in GCL documentation "If you want concurrency performance, ... to compile Groovy scripts in your application, use GroovyScriptCompiler."Make GCL functionality private, or at least add the same comment there. Rationale: From what I have read

Re: Java raw string literals

teral (i.e. one that strips away newline and whitespaces automatically). Not sure whether that would make sense to put this inside the string quoting syntax, though. Cheers, mg On 24.02.2018 17:43, Daniel.Sun wrote: Double backticks look a bit ugly IMO... I prefer the same way to escape,

Re: [GEP] Concatenative Method Calls

Hi Daniel, I agree with Andrew, the example to me looks less readable. Do you have another example that shows what application you had in mind ? Cheers,mg Ursprüngliche Nachricht Von: Andrew Bayer Datum: 25.02.18 15:02 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: [GEP

Re: [GEP] Concatenative Method Calls

Intuitively the => arrow-operators point in the wrong direction, since I feel foo gets applied to x, etc... How would additional arguments to an intermediate function be handled in this syntax ? Ursprüngliche Nachricht Von: "Daniel.Sun" Datum: 25.02.18 14:38 (GMT+01:00) An: d

Re: [GEP] Concatenative Method Calls

Intuitively the => arrow-operators point in the wrong direction, since I feel foo gets applied to x, etc... How would additional arguments to an intermediate function be handled in this syntax ? Ursprüngliche Nachricht Von: "Daniel.Sun" Datum: 25.02.18 14:38 (GMT+01:00) An: d

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

You mean http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html ? On 01.03.2018 18:34, Cédric Champeau wrote: You have to be aware that this java syntax prepares the way for pattern matching. I think we need to wait and see before doing it. Le 1 mars 2018 17:45, "Paolo Di Tommaso"

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

+1 on Java compatibility, otherwise not a big fan of switch statments, I have always found the syntax inelegant and the appliaction domain too limited. But it looks like with pattern matching and without the need to use break it could finally become less of a Mauerblümchen-statement for me...

Re: [GEP] Concatenative Method Calls

As somebody who routinely works with Groovy ( ;-) ) I agree with all of that. Using e.g. |> instead of => seems to me a much better choice, for a multitude of reasons. While I personally do not have big need for such an operator, and am generally a fan of using fluent method chaining (when I d

Re: Groovy Champions proposal feedback

...and, of course, the Apache Groovy Community Lifetime Achievement Award ;-) Like the name, +1 (again) on tying the award to a specific year, don't think that mixing commit access with the award makes sense (as in programming: Keep things single purpose - nobdy wants to be fat, be it class

Re: About supporting `var` of Java10+

var/final === def in all other cases for now. If someone wants to / has time, he can improve on this later. My 8.05762816 Cent, mg On 08.03.2018 00:53, Daniel Sun wrote: Hi all, As GROOVY-8498[1] describes as follows, in order to compatibility with Java 10+, Groovy should support `var

Re: About supporting `var` of Java10+

would not expect to use that a lot. Ursprüngliche Nachricht Von: Jochen Theodorou Datum: 08.03.18 04:50 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: About supporting `var` of Java10+ On 08.03.2018 02:23, MG wrote: > Hi Daniel, > > I agree that it does not make

Re: About supporting `var` of Java10+

Theodorou Datum: 08.03.18 10:57 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: About supporting `var` of Java10+ Am 08.03.2018 um 09:44 schrieb mg: > @unless you reassign, you would not notice the difference between current > def and the Java var: > 1) If I don't need to rea

Re: About supporting `var` of Java10+

Hi Paul, I would be interested to hear if you see some advantages of going down the#define var defroute - apart from the obvious, that it is the easiest/fastest to implement ? Cheers,mg Ursprüngliche Nachricht Von: Paul King Datum: 08.03.18 12:26 (GMT+01:00) An: dev

Re: About supporting `var` of Java10+

other words, “int var = 10;” is still legal. I’m thinking we should remain as conservative as Java in those matters. -Jesper > On 8 Mar 2018, at 02.23, MG wrote: > > Hi Daniel, > > I agree that it does not make much sense to closely mirror the details of the > Java specif

Re: About supporting `var` of Java10+

otherwise I would use final instead of var... Ursprüngliche Nachricht Von: Jochen Theodorou Datum: 08.03.18 13:32 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: About supporting `var` of Java10+ Am 08.03.2018 um 12:45 schrieb mg: > Maybe I am missing your point, but what I me

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

uot;Neither Foo nor Bar, hmmm...");  3; ) } or int result = switch (s) {     case "Foo" -> 1;     case "Bar" -> 2;     case PATTERN_ANY -> { System.out.println("Neither Foo nor Bar, hmmm...");  3; } } etc ? I am in the "never liked break camp&q

Re: About supporting `var` of Java10+

ng wrote: So in that one aspect of "assigning a value later on" your expectation is exactly like Java's "var" and Groovy's current "def"? On Thu, Mar 8, 2018 at 11:58 PM, mg <mailto:mg...@arscreat.com>> wrote: My argument was not in rel

Re: About supporting `var` of Java10+

On 08.03.2018 14:13, Paul King wrote: On Thu, Mar 8, 2018 at 9:53 PM, mg <mailto:mg...@arscreat.com>> wrote: I would be interested to hear if you see some advantages of going down the #define var def route - apart from the obvious, that it is the easiest/f

Re: About supporting `var` of Java10+

On 09.03.2018 00:01, Paul King wrote: But Java doesn't have a dynamic mode so it is difficult to offer the exact same behavior. We could prohibit "var" from being used in dynamic Groovy but users might expect to be able to cut and paste from Java and run in dynamic mode. I am convinced that

Fund Groovy Development - Jira Task

patible" topic at the top of the funding table in https://issues.apache.org/jira/browse/GROOVY-8503. Cheers, mg *I think we should see if this appoach does not suffice, before going down the route of a Kickstarter/Indiegogo/tribe.taiga.io/bountysource.com/Patroon/fundrequest.io - tha

Re: Fwd: About supporting `var` of Java10+

e RHS type for final, I need to keep my current code, or force framework users to use @CompileStatic on all Table derived classes, if they want to define table columns in the most elegant and concise way... :-) mg On 10.03.2018 14:23, Jochen Theodorou wrote: On 10.03.2018 03:

Re: Fwd: About supporting `var` of Java10+

On 11.03.2018 14:58, Jochen Theodorou wrote: On 10.03.2018 20:33, MG wrote: Hi Jochen, I was not aware that Groovy is so sophisticated in its expression analysis, that it actually uses intersection types you actually do not have much of a choice. It is an AST-only representation only

Re: Fwd: About supporting `var` of Java10+

query would have to be defined taking more than double the necessary space - that would not be Groovy, sondern Java... ;-) lg, mg On 12.03.2018 07:52, Jochen Theodorou wrote: On 11.03.2018 17:29, MG wrote: On 11.03.2018 14:58, Jochen Theodorou wrote: On 10.03.2018 20:33, MG wrote: Hi J

Re: Fwd: About supporting `var` of Java10+

c than var === def) Cheers, mg On 12.03.2018 07:52, Jochen Theodorou wrote: On 11.03.2018 17:29, MG wrote: On 11.03.2018 14:58, Jochen Theodorou wrote: On 10.03.2018 20:33, MG wrote: Hi Jochen, I was not aware that Groovy is so sophisticated in its expression analysis, that it actually uses in

Re: [GEP]Lazy evaluation for Groovy 3

() // keyword style 3. final records = proxy(doQueryFromDB()) // function style 4. Something with @Lazy(proxy=true) ? Cheers, mg On 17.03.2018 14:21, Suderman Keith wrote: +1 for the concept. -1 for using parenthesis.  As Andrew says, this introduces new behaviour for parenthesis that I think

Re: [GEP]Lazy evaluation for Groovy 3

suggest them... :-) Cheers,mg Ursprüngliche Nachricht Von: "Daniel.Sun" Datum: 18.03.18 06:15 (GMT+01:00) An: d...@groovy.incubator.apache.org Betreff: Re: [GEP]Lazy evaluation for Groovy 3 Hi mg, I am not going to add new syntax to groovy 3.0 as much as possible.

Re: [GEP]Lazy evaluation for Groovy 3

suggest them... :-) Cheers,mg Ursprüngliche Nachricht Von: "Daniel.Sun" Datum: 18.03.18 06:15 (GMT+01:00) An: d...@groovy.incubator.apache.org Betreff: Re: [GEP]Lazy evaluation for Groovy 3 Hi mg, I am not going to add new syntax to groovy 3.0 as much as possible.

Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]

In general I agree that the half-open interval [TS_FROM, TS_TO) should be the default behavior for intervals due to the reasons given - whatever detailed influence that has on discrete iterations / upto/downto :-) Cheers, mg On 18.03.2018 17:45, Alexander Veit wrote: Hi, 2) changing the

Re: [RFE] Methods as expressions

e) = Hello $name" (why did you use a return keyword in your sample ?) I dont see an improvement in readability here - the main "advantage" is that curly braces are annoying to input on non-US keyboard layouts ;-) mg Ursprüngliche Nachricht Von: Cédric Champeau Dat

Re: [RFE] Methods as expressions

PS: I am also worried that unecessarily deviating from Java syntax would make it harder for Java devs to pick up Groovy... Ursprüngliche Nachricht Von: Cédric Champeau Datum: 20.03.18 11:41 (GMT+01:00) An: dev@groovy.apache.org Betreff: [RFE] Methods as expressions Hi, One

Re: [RFE] Methods as expressions

this is. It's an expression, a _function_. On the other hand, { ... } declares a block, that could represent an expression, or a statement, or a list of statements, one of them returning an expression. I like the declaration of intent. 2018-03-20 12:20 GMT+01:00 mg : Am having a migraine right

Re: [RFE] Methods as expressions

the other hand, { ... } declares a block, that could represent an expression, or a statement, or a list of statements, one of them returning an expression. I like the declaration of intent. 2018-03-20 12:20 GMT+01:00 mg : Am having a migraine right now so hard to concentrate / think straight bu

Re: [RFE] Methods as expressions

useful. Perhaps the = could be replaced, but I certainly like the idea of having more expression oriented syntax in Groovy. Java itself seems to be moving in this direction with the proposed switch expression syntax?  This feels very similar? On 20 March 2018 at 11:39, mg wrote: @style rules: Th

Re: next generation CliBuilder?

+1 from my side :-) On 20.03.2018 18:26, Remko Popma wrote: Would there be any interest in a next generation CliBuilder that is based on [picocli][1] instead of commons-cli? This would enable new features like: * support for nested [subcommands][2] * strongly typed [positional parameters][3] *

Re: next generation CliBuilder?

the library ? Or are there any other (long running) plans to replace the existing CliBuilder implementation ? Cheers, mg On 20.03.2018 19:13, Russel Winder wrote: On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote: Would there be any interest in a next generation CliBuilder that is based on

Re: [RFE] Methods as expressions

On 20.03.2018 16:19, eric.mil...@thomsonreuters.com wrote: Java syntax for a default method value is: public@interfaceDelegate{ boolean*interfaces*() defaulttrue; Is there really a need to introduce another form when the saving is actially 0 characters (colon and equals vs open and close bra

Re: [RFE] Methods as expressions

On 20.03.2018 17:16, David Dawson wrote: To give an alternate take on the topic. The best thing in Groovy when it first started gaining adoption was this ["hello"], "world"].collect {   it * 2 }.each { println it } Utterly incompatible with Java, happily destroying its idioms. Collection li

Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]

1) Very much in favor of  "parse this String with this pattern" (for all the reasons given) :-)2) Agree that "strict/unit/exact" should be replaced by more intuitive / self explanatory alternatives if possible.Cheers,mg Ursprüngliche Nachricht Von: Joe Wolf

Re: [RFE] Methods as expressions

od in Rust ? Cheers,mg Ursprüngliche Nachricht Von: David Dawson Datum: 21.03.18 10:07 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: [RFE] Methods as expressions in Rust, control flow statements are expressions. Partly this was done to enable the lifetimes to be more

Re: [RFE] Methods as expressions

a closure, since return statements have this expression property already: final foo = ({ -> if(...) { ... }   else if(...) { ... }   else if(...) { ... }   else { ... } }()) *From:*mg [mailto:mg...@arscreat.com] *Sent:* Wednesday, March 21, 2018 4:03 PM *To:* dev@groovy.apache.org *Subje

Re: [RFE] Methods as expressions

would support break/return/continue: https://issues.apache.org/jira/browse/GROOVY-8301 :-) Cheers, mg On 22.03.2018 00:06, David Dawson wrote: In rust, the generally promoted style is to not use returns if you can avoid it, and have the final expression in a particular block evaluated for t

Re: About triple quoted string

Unless one of the EOG* sees a problem with that, that would be a helpful improvement in my case, since I have occasionally run into that in my SQL generator (I assume it also works for double quotes, Daniel ?) :-)mg *Elders of Groovy Ursprüngliche Nachricht Von: Paul King

Re: About triple quoted string

Just saw that Daniel's mail already showed a '"' and "'" example... Ursprüngliche Nachricht Von: mg Datum: 30.03.18 16:52 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: About triple quoted string Unless one of the EOG* sees a problem

Re: new MOP under Java9 module system findings

a general "Denkanstoß" / food for thought, Cheers, mg On 01.04.2018 18:33, Jochen Theodorou wrote: Hi all, yesterday I was playing around with java modules and tried to implement some pseudo mops based on what we have and I'd like to share my impressions. Please do not wonder t

Re: new MOP under Java9 module system findings

ion.html ... ) On 01.04.2018 20:15, Jochen Theodorou wrote: On 01.04.2018 19:58, MG wrote: Hi Jochen, I just thought about some post by another project I read some time back (alas I can no longer remember which project exactly) which used Groovy as its scripting language, but switched to a lesse

RE: new MOP under Java9 module system findings

oovy 3.0 Java lambda support compare to Painless ? Cheers,mg Ursprüngliche Nachricht Von: Uwe Schindler Datum: 02.04.18 12:11 (GMT+01:00) An: dev@groovy.apache.org, 'Jochen Theodorou' , d...@groovy.incubator.apache.org Betreff: RE: new MOP under Java9 module system

RE: new MOP under Java9 module system findings

oovy 3.0 Java lambda support compare to Painless ? Cheers,mg Ursprüngliche Nachricht Von: Uwe Schindler Datum: 02.04.18 12:11 (GMT+01:00) An: dev@groovy.apache.org, 'Jochen Theodorou' , d...@groovy.incubator.apache.org Betreff: RE: new MOP under Java9 module system

Groovy 3.0 Java Lambda

ava lambda ? Cheers,mg

Re: Groovy 3.0 Java Lambda

focusedCommentId=16424692&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16424692 ) Cheers, mg On 04.04.2018 00:03, Jochen Theodorou wrote: On 03.04.2018 19:17, mg wrote: With regards to Groovy 3.0 Java lambda support: Is it practically doable to turn a Groovy closure into a Groovy Java lambda if onl

Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

Hmmm - is it really worth introducing this feature for a temporary backward compatibility fix, especially considering Paul himself is mentioning some security concerns ? Wouldn't it be better to supply e.g. a small tool that converts Groovy pre-module-code to Groovy 3.0 code (could CodeNarc be u

Re: About the Phoenix plan for Groovy

tatic for some reason fails, so unless the bug is in a really time critical part of the code, you always* have a workable workaround at hand... @Cents(10)mg *except in the Minecraft Forge obfuscation case, of course ;;;-) Ursprüngliche Nachricht Von: Daniel Sun Datum: 08.04.18

Re: About the Phoenix plan for Groovy

tatic for some reason fails, so unless the bug is in a really time critical part of the code, you always* have a workable workaround at hand... @Cents(10)mg *except in the Minecraft Forge obfuscation case, of course ;;;-) Ursprüngliche Nachricht Von: Daniel Sun Datum: 08.04.18

  1   2   3   4   5   >