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:

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

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

quot; is any worse than "all", just a point to keep in mind when picking names ... Cheers, Paul. On Thu, Nov 23, 2017 at 8:53 AM, MG <mg...@arscreat.com> wrote: I like groovy-standalone.jar as a name (clearer than "all"). Alas changing names breaks al

Re: Building Groovy

or 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 <mg...@arscreat.com>: I was thinking the same. Without being all for changing the name,

Re: Building Groovy

build 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 <mg...@arscreat.com <mailto:mg...@arscreat.com>>:     I

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

Re: Package specific syntax

a 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 <daniil.ovchinni...@jetbrains.com> Datum: 15.12.17

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

Re: Building Groovy

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 mechanism: h

Re: Building Groovy

s 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 t

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:

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

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

, etc. Cheers, mg

Re: Is FieldsAndPropertiesStaticCompileTest#testUseGetterFieldAccess really correct?

=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 getterCalled = false

Re: [DRAFT] Proposed board report for Apache Groovy for May 2018

@Groovy downloads x2: Great news! :-) Ursprüngliche Nachricht Von: Guillaume Laforge Datum: 07.05.18 11:39 (GMT+01:00) An: dev@groovy.apache.org, Paul King Betreff: Re: [DRAFT] Proposed board report for Apache Groovy for May 2018 Hi

Re: What the... static compile by default

Hi Daniel, On 12.05.2018 15:51, Daniel.Sun wrote: Hi mg, I am trying to reduce the time on smart phone and computer to relax eyes :) That sounds like a good idea :-) (Have you already tried reducing the blue component on every display ? I do that with every monitor - at first

Re: [VOTE] Support Java-like array

has 2 x +1, just push it over the edge, if you are really against it, shoot it down with -1... Cheers, mg On 13.05.2018 10:57, Paul King wrote: My understanding is that there is some flexibility when asking for votes so long as it is clear up front what the expectation is, see e.g. [1]. Even

Re: [VOTE] Support Java-like array

What I meant to say yesterday at 1am was: "On the other hand I do not get why only 2 PMC members have been voting +1 on this proposal..." This is not against voting +0, but about why so few PMC members vote at all... (?) Ursprüngliche Nachricht --------Von: MG <mg...

Re: What the... static compile by default

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: [VOTE] Support Java-like array

ow hard can it be to add errors which do not make the build fail ?-)  ) Cheers, mg

Re: [DRAFT] Proposed board report for Apache Groovy for May 2018

If I would venture a guess, and gauging from articles in magazines, I would say the upcoming Groovy 3.0 major release creates quite some buzz... Cheers, mg On 07.05.2018 15:34, Daniel.Sun wrote: Yep. It is a great news. As you all know, Groovy is lack of marketing, so I wonder why Groovy

Re: What the... static compile by default

the lowest priority, it should not collide with all the existing ways to apply @CompileStatic to Groovy code) ? Cheers,mg Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org> Datum: 07.05.18 16:59 (GMT+01:00) An: d...@groovy.incubator.apache.org Betre

Re: What the... static compile by default

the lowest priority, it should not collide with all the existing ways to apply @CompileStatic to Groovy code) ? Cheers,mg Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org> Datum: 07.05.18 16:59 (GMT+01:00) An: d...@groovy.incubator.apache.org Betre

Re: [VOTE] Support Java-like array

00% equivalent & concise Groovy closure syntax here instead). Cheers,mg Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org> Datum: 04.05.18 03:38 (GMT+01:00) An: d...@groovy.incubator.apache.org Betreff: [VOTE] Support Java-like array Dear deve

Re: [VOTE] Support Java-like array

00% equivalent & concise Groovy closure syntax here instead). Cheers,mg Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org> Datum: 04.05.18 03:38 (GMT+01:00) An: d...@groovy.incubator.apache.org Betreff: [VOTE] Support Java-like array Dear deve

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

org Cc: pa...@asert.com.au Betreff: Re: [DISCUSS] Renumber Groovy 2.6 to 2.9 I’d suggest to keep it simple, go with 2.9.0.  Sent from my primitive Tricorder On 20 May 2018, at 21:50, mg <mg...@arscreat.com> wrote: What about 2.97 ? Incorporates a JDK 7 reference, and is not too close to 3.0

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

What about 2.97 ? Incorporates a JDK 7 reference, and is not too close to 3.0 (Bugfixes could go into 2.97.1 etc..., so the "7" could be kept). Ursprüngliche Nachricht Von: Russel Winder Datum: 20.05.18 12:26 (GMT+01:00) An: pa...@asert.com.au,

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

Keith On May 20, 2018, at 10:01 AM, Cédric Champeau <cedric.champ...@gmail.com> wrote: +1 but alternatively, we could just skip 2.6 and go straight to 3.0. Le dim. 20 mai 2018 à 15:25, mg <mg...@arscreat.com> a écrit : 2.9.0 could make people ask themselves where 2.6/2.7/2.8 went, whereas 2.

Re: Java object conversion using ConfigSlurper

Non-PMC +1 on using getAs, because I feel the semantics are sufficiently different, and trying to retrofit this might lead to unexpected edge cases now and/or headaches in the future. What do others think ? Ursprüngliche Nachricht Von: adithyank Datum:

Re: Java object conversion using ConfigSlurper

Non-PMC +1 on using getAs, because I feel the semantics are sufficiently different, and trying to retrofit this might lead to unexpected edge cases now and/or headaches in the future. What do others think ? Ursprüngliche Nachricht Von: adithyank Datum:

Re: Java object conversion using ConfigSlurper

I guess it boils down to whether the semantics/intention of getAs is different from asType or not (no Groovy magic expected ?...) Ursprüngliche Nachricht Von: adithyank Datum: 16.05.18 12:52 (GMT+01:00) An: d...@groovy.incubator.apache.org Betreff: Re:

Re: Java object conversion using ConfigSlurper

I guess it boils down to whether the semantics/intention of getAs is different from asType or not (no Groovy magic expected ?...) Ursprüngliche Nachricht Von: adithyank Datum: 16.05.18 12:52 (GMT+01:00) An: d...@groovy.incubator.apache.org Betreff: Re:

Re: 2.5.0-rc-3

Is the intention to switch to a rapid major release cycle like Windows, Java, etc ? If yes: Shouldn't we then call the next major release Groovy 18 (or 19, depending on year of release) ? Could also be: groovy 2.6 -> groovy 18.0groovy 3.0 -> groovy 19.0 What exactly would be in 4.0 ? Going to

Re: 2.5.0-rc-3

Hi Paul & Russel, thank you for claryfying that. Do you have a rough idea what an early 3.0 release would mean time-and feature wise ? Cheers,mg Ursprüngliche Nachricht Von: Paul King <pa...@asert.com.au> Datum: 22.05.18 16:28 (GMT+01:00) An: dev@groovy.apache.org B

Re: Performance of the compiler

Hi Cedric, to put this in context and to better understand the ongoing discussion: How many tests and what absolute compile time are we talking about here ? Cheers,mg Ursprüngliche Nachricht Von: Cédric Champeau <cchamp...@apache.org> Datum: 24.05.18 08:30 (GMT

Groovy 2.5 @Macro ?

sert x ==123 assert nv(x) =="x" } @Macro Expression nv(MacroContext ctx, VariableExpression variable) { return constX(variable.getName()); } } What is missing to make this work ? mg

Re: Proposed Groovy 3.0 Scope

Hi Jesper, good overview document, thank you & would be great if you could help with Groovy 3.0 :-) I agree that what is needed is progression towards decisions on some key questions... Cheers,mg PS: Under:"Lambda syntax for closures - Done-ish? (native lambda is enabled only in t

Re: About raw string and enhanced try-with-resource

ses maybe use an annotation-like syntax: // "\n" appears as the char sequence {\,n} in the resulting string // strings given as arguments to @S(...) are always literal final GString multilineRegularexpressionInterpolatedWithSpecificCharsInterpretedLiteral =  @S("ri",["\n"])"age:(\d+)phone:${telephoneNumberRegex}\n\n\n" Cheers, mg

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

Good point.  This is one reason why - under the given constraints - Russel's 2.99.x or my 2.97.x would be better choices than 2.9.x(once you get beyond "this is not how things are done"). Also consider what happens if, for some reason, the current 2.5.x branch was to continue beyond 2.5.x

Re: Groovy 2.5 @Macro ?

g/codehaus/groovy/macro/MacroTransformationTest.groovy ? Cheers, mg On 26.05.2018 00:00, MG wrote: Hi guys, giving the new Groovy 2.5 macro functionality a spin, and would have expected the code below to replace the "call" to nv(x) with the AST expression created in the method, i.e

Re: Groovy 2.5 @Macro ?

com> Datum: 26.05.18 18:12 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Groovy 2.5 @Macro ? I didn't check, but I _think_ you can't define a macro and use it in the same file. Le sam. 26 mai 2018 à 17:15, MG <mg...@arscreat.com> a écrit : I would have expected

Re: Groovy 2.5 @Macro ?

Hi Paul, why this restriction ? I thought this feature was here to e.g. simply support logging of the form "$variableExpression.name=$variableExpression.value", etc: https://github.com/bsideup/macro-methods-workshop/blob/master/src/test/groovy/com/example/SuperLoggerMacroTest.groovy ?

Re: Groovy 2.5 @Macro ?

Hi Guillaume, yes, there seems to be nothing on @Macro. Cheers,mg Ursprüngliche Nachricht Von: Guillaume Laforge <glafo...@gmail.com> Datum: 26.05.18 21:15 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Groovy 2.5 @Macro ? Did you also check the documentatio

Re: Groovy 2.5 CliBuilder article (request for feedback)

Hi Paul, @release notes:@MapConstructor adds a Map-based constructor . This may be useful if you have final properties I can assure you that this _is_, in fact, greatly useful, so might want to change "may be" to "is" if time allows :-) Cheers,mg Ursprüngliche N

Re: Groovy 2.5 CliBuilder article (request for feedback)

Great, excited, 2.5 really has a lot of really good stuff :-) Ursprüngliche Nachricht Von: Paul King Datum: 30.05.18 05:59 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Groovy 2.5 CliBuilder article (request for feedback) I have started the release process. I expect it

IntelliJ: Full Groovy 2.5.0 Support

Hi, I have created a Jetbrains issue you can vote on for IntelliJ to fully support Groovy 2.5 as soon as possible :-) https://youtrack.jetbrains.com/issue/IDEA-193168 Cheers, mg

Re: Groovy 2.5 @Macro ?

May 27, 2018 at 10:02 AM, mg <mg...@arscreat.com> wrote: Hi Paul, why this restriction ? I thought this feature was here to e.g. simply support logging of the form "$variableExpression.name=$variableExpression.value", etc: https://github.com/bsideup/macro-methods-workshop/blob/master

Groovy Name-and-Value Macro Support Proposal

re used to macros will immediately suspect that they are looking at a macro-like construct 4. Independent of upper-/lowercase, brevity is important, especially for the proposed two NV/NVL macros, since it would imho be desirable for e.g. "NV(x)" to not take up more space than "x=$x" In any case macro-method support in Groovy is a fantastic feature, which opens up completely new possibilities for language & framework developers - Go Groovy !-) Please comment, Cheers, mg

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... ?-) ).

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... ?-) ).

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

bove, 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: G-String embedded Closure calling bug?

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. What do you guys think ? mg

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

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

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 <blackd...@gmx.org> Datum: 23.12.17 13:13 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Gradle build updates

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 <mg...@arscreat.com> Datum: 23.12.17 15:32 (GMT+01:00) An: dev@groovy.apache.org Cc: Jochen Theodorou <blackd...@gmx.org>

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 <mg...@arscreat.com> Datum: 23.12.17 14:43 (GMT+01:00) An: dev@groovy.apache.org Cc: Jochen Theodorou <blackd...@gmx.org>

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

Re: Making @Immutable a meta-annotation

at least 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 On 15.

Re: Making @Immutable a meta-annotation

ere also), 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 <mg...@arscreat.com <mailto:

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: 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 normal examples

Re: Making @Immutable a meta-annotation

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 <pa...@asert.com.au> Datum: 13.01.18 13:17 (GMT+01:00) An: MG <mg.

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 <

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 23.01.

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: About the callable native lambda

xist" 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...)" means: - Non-SA

Re: Java raw string literals

ng literal (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: 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: Building Groovy

On 19.12.2017 09:37, Cédric Champeau wrote: 2017-12-19 2:21 GMT+01:00 MG <mg...@arscreat.com <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 t

Re: toDebugString as a Groovy core concept

String as a Groovy 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 <mg...@arscreat.com> wrote: Hi all, I

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: preparing for release 2.5.2

Hi Paul, on vacation right now, but what about including the "named variable" @Macro feature I proposed a as an experimental feature, to get user feedback ? Cheers,mg Ursprüngliche Nachricht Von: Paul King Datum: 09.08.18 08:37 (GMT+00:00) An: dev@groovy.apache.o

Re: suggestion: ImplicitSafeNavigation annotation

since there is no universal support for e.g. an EMPTY constant (explicitely expressing "uninitialized")).  Ursprüngliche Nachricht Von: "ocs@ocs" Datum: 15.08.18 03:18 (GMT+00:00) An: dev@groovy.apache.org Betreff: Re: suggestion: ImplicitSafeNavigation annota

Re: suggestion: ImplicitSafeNavigation annotation

will not necessarily give null. Ursprüngliche Nachricht Von: "ocs@ocs" Datum: 15.08.18 03:18 (GMT+00:00) An: dev@groovy.apache.org Betreff: Re: suggestion: ImplicitSafeNavigation annotation mg, On 15 Aug 2018, at 3:26 AM, mg wrote: Fair enough (I am typing this on my smartp

Re: suggestion: ImplicitSafeNavigation annotation

s@ocs" Datum: 15.08.18 03:18 (GMT+00:00) An: dev@groovy.apache.org Betreff: Re: suggestion: ImplicitSafeNavigation annotation mg, On 15 Aug 2018, at 3:26 AM, mg wrote: Fair enough (I am typing this on my smartphone on vacation, so keep samples small; also (your) more complex co

Re: suggestion: ImplicitSafeNavigation annotation

by side example :-) Cheers,mg *at least, to be precise, because the same goes for minus, divide, etc Ursprüngliche Nachricht Von: "ocs@ocs" Datum: 15.08.18 19:53 (GMT+00:00) An: dev@groovy.apache.org Betreff: Re: suggestion: ImplicitSafeNavigation annotation Eric,

Re: suggestion: ImplicitSafeNavigation annotation

Sorry, bad/incorrect example, should read: Do you expect/want true && null == null  // null == UNKNOWN or true && null == false // Groovy-truth-null ? Ursprüngliche Nachricht Von: "ocs@ocs" Datum Ursprüngliche Nachricht Von: mg Datum:

Re: suggestion: ImplicitSafeNavigation annotation

) {    if(nullSafeQ) {      return null    }    throw e  }} (It feels a bit like what you wants is tri-logic/SQL type NULL support in Groovy, not treating Java/Groovy null differently...) Cheers,mg Ursprüngliche Nachricht Von: "ocs@ocs" Datum: 14.08.18 17:46

Re: suggestion: ImplicitSafeNavigation annotation

) Ursprüngliche Nachricht Von: "ocs@ocs" Datum: 14.08.18 23:14 (GMT+00:00) An: dev@groovy.apache.org Betreff: Re: suggestion: ImplicitSafeNavigation annotation mg, On 14 Aug 2018, at 11:36 PM, mg wrote: I am wondering: In what case does what you are using/suggesting differ signific

Re: suggestion: ImplicitSafeNavigation annotation

8 00:53 (GMT+00:00) An: dev@groovy.apache.org Betreff: Re: suggestion: ImplicitSafeNavigation annotation mg, On 15 Aug 2018, at 1:33 AM, mg wrote: That's not how I meant my sample eval helper method to be used :-) (for brevity I will write neval for eval(true) here) What I meant was: How eas

Re: ModuleNode and CompuleUnit

Alias + deprecate in 2.5.3, delete in 2.5.4 - we need to get up to JDK speed here, guys (& gals)... ;-) Ursprüngliche Nachricht Von: Paul King Datum: 13.08.18 10:56 (GMT+00:00) An: dev@groovy.apache.org Betreff: Re: ModuleNode and CompuleUnit We could provide an alias I

Re: suggestion: ImplicitSafeNavigation annotation

18 02:20 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: suggestion: ImplicitSafeNavigation annotation mg, if you think there's any commutative operator in Groovy, you are in for a very nasty surprise. There's not, never has been, and — unless some future release decides to very seriously break

Re: looks like a compiler bug?

Wouldn't it be easier/better to require stuff like that (which will be a programming error in 99.999...% of cases) require an e.g. @LenientMode annotation to not raise a compilation error (wherever that error is located) ? class Foo {   @LenientMod   void baz() { return 42 } // compiles &

Re: Inconsistent overriding of Interger methods

Without having looked at the implementation: Wouldn't "performance" be a plausible explanation why these cases can't be moped up... ? Ursprüngliche Nachricht Von: Paul King Datum: 20.08.18 02:59 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Inconsistent overriding of

Re: suggestion: ImplicitSafeNavigation annotation

of someone explicitely throwing an NPE in a method... ;-) @null.each { ... } : That would be my expectation also, but afaik null.each behavior in dynamic Groovy has been around long before Elvis entered the building... Cheers,mg Ursprüngliche Nachricht Von: "ocs@ocs" Datum:

Re: bool

Precisely, and since we were talking about boolean/Boolean, the name does not fit both shoes :-) Ursprüngliche Nachricht Von: Jochen Theodorou Datum: 23.07.18 22:36 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: bool Am 23.07.2018 um 16:35 schrieb mg: [...] > &q

Re: bool

for a boolean variable makes little sense to me, since bools basically cry out to express what true means in their name. So using bool as a name is close to using obj0, obj1, obj2, ... for all your variables to me... Cheers,mg Ursprüngliche Nachricht Von: Jennifer Strater Datum: 23.07.18

Re: bool

:37 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: bool On Mon, 2018-07-23 at 16:35 +0200, mg wrote: > A quick search did not turn up anything on Kotlin using bool instead > of boolean. Do you have a link ? Maybe I just mis-remembered. If it is the case that Kotlin is using Boolean no

fin

Therefore I propose to introduce the shortcut "fin" for "final" in Groovy. e.g. to support class Goo {     fin String name     fin Goo gooParent     Goo(fin String name, fin Goo gooParent) { ... }     String gooGoal(fin x) {         fin y = 2*x         fin int z = x + y     } } Cheers, mg

Re: fin

e pointed out before, "final" is solely a modifier in Java, and cannot be used as a type, as in Groovy). 3. I don't see any examples usinf "final" now, so all new examples could use "fin". Cheers, mg On 22.07.2018 01:03, J. David Beutel wrote: Personally,

bool

n" saves nearly half of the keyword's characters, "bool" is used in C++, it fits better with the also widely used "int", and Groovy 3.0 is the ideal opportunity to introduce such language extensions. Cheers, mg

Re: fin

ld /actually /use final, while supplying the exact same amount of succcintness ?-) Cheers, mg On 22.07.2018 08:53, Paul King wrote: I am probably -1 right now on a new keyword when I think the existing one works just fine. One reason some Groovy folks might not use final more frequently is b

Re: fin

def or var (and for immutability there is the new improved Groovy immutable support). Cheers, mg On 22.07.2018 20:23, Suderman Keith wrote: -1 Coming from a C/C++ background that has `const` I typically do not use final because it does not give me a truly final (const) object and users can still do:

Re: bool

Hi Jenn, @bool: You are right "bool" is of course used by many languages, including Python :-) @meaning of "fin": I was thinking of the French word for "end". Cheers,mg Ursprüngliche Nachricht Von: Jennifer Strater Datum: 22.07.18 23:57 (GMT+01:

Re: bool

atum: 23.07.18 10:22 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: bool On Sun, 2018-07-22 at 23:39 +0200, MG wrote: > Hi, > > since things are going so well with my "fin" = "final" proposal, I > propose that Groovy support "bool" as a shortcut f

Re: bool

on, 2018-07-23 at 12:40 +0200, mg wrote: > I wanted to keep my mail concise, but also aliasing Bool = Boolean > was more or less implied, for consistency & brevity reasons. > I would also think that Java would introduce Int = Integer, or use > int = Integer in that case... When i

  1   2   3   4   >