Yeah, it will be one of those subjective things. Some folks think it is ugly to have to type "Color.RED" when Java lets you just type "RED". We have that down to just one case now (or you can use an import) but for dynamic Groovy we probably can't do better. The GEP proposal would give another option. And for some folks all the extra places they can shorten using a consistent pattern might seem like a beautiful thing to them, but yes I still fall into the camp of "it looks a little awkward", but I am still keen to explore the possibilities.
Cheers, Paul. On Wed, Jul 29, 2026 at 6:25 AM MG <[email protected]> wrote: > > Just a quick feedback for GEP-28: I saw that "Sigil variants" (@RED, > :RED, etc) are already stated as rejected in the GEP, but what about > something similar to Groovy's "it" in closures (maybe as an option, to > also be able to break ambiguities without having to fall back to the > current fully qualified notation) ? > To me the floating-in-free-air-dot-prefix notation ( .RED ) looks like > an error / ugly... > > Cheers, > mg > > Am 28.07.2026 um 08:30 schrieb Paul King: > > Hi folks, > > > > I created two more draft GEPs tentatively targeting Groovy 7: > > > > * GEP-28 is about supporting DOT-notation that is supported by Dart and > > Swift. > > [I like the brevity it gives but it also takes some getting used to > > and it complicates things if Java ever develops a different compact > > syntax.] > > > > * GEP-29 is about supporting deeper null checking. > > [This is really about whether we want to fully support JSpecify which > > seems to be gaining momentum. NullChecker in Groovy 6 already offers > > partial support.] > > > > I don't really have the cycles to do major reviews of the GEPs yet, > > and I expect both will go through several iterations when we do. For > > both we should ask ourselves whether we need the feature and weigh up > > each's value against the increased complexity. But I wanted to capture > > the ideas anyway, since I think they are worth thinking about in due > > course. We should be comfortable with rejecting GEPs if the ideas > > don't belong or belong somewhere else. > > > > To be honest, we already have a backlog of potential Groovy 7 features > > that will keep us busy for a while. > > > > But if other folks want to jump ahead and think about them, feel free. > > > > Cheers, Paul. >
