> What you call "Java Compatibility" many Groovy users would call expected features.
> My suspicion is that for each feature you might want to move into a > "Similarities with Java" chapter, there will be some users that regard > that feature as a critical Groovy feature. If Groovy gets diluted with the Java syntax we are going to loose the "Groovyness" and we should stop talking about "Idiomatic Groovy" (and all this thing about `var` is not needed by Groovy and is not idiomatic Groovy, this thing about `var` smells like fear in any way you want to look at it). You folks are starting to feel weak, scared and probably tired. You feel "safer" promoting writing Java code with Groovy? Because that does not make any sense whatsoever. I believe all this "forcing Kotlin everywhere for any reason" thing is taking up not only the Groovy space, but some space in our minds where it is not supposed to be. > But perhaps that information can be in a sidebar > with a preface letting non-Java developers know that they can safely > ignore "var" if they want to. I suggest we talk about Groovy as the main language and we put on side notes, as you suggest, where we can use the Java syntax to achieve the same results. So we don't have a separate chapter and the Java "alternative" is inline with the documentation. But the Groovy syntax always gets first, and the Java "alternative" on a side note. Unless this is all about suggesting Groovy to newbies as a step to learn coding before transitioning to Java. This is my message, and I want to scream it: GROOVY FIRST. Cheers, Gianluca > [1] https://groovy-lang.org/differences.html > > > > Cheers, > > Gianluca > > > >> > >> Cheers, Paul. > >> > >> On Fri, Nov 29, 2024 at 6:45 PM Gianluca Sartori <g.sart...@gmail.com> > wrote: > >> > > >> > Paul, I don't know why you think that I don't want to use `var` since > I've opened the discussion with: > >> > > >> > > I would like to start using the more Java-ish `var` instead of the > Python-ish `def` lexicon > >> > > >> > I've been tagged to pose weak arguments but I really think the > argument of wanting "Java developers to be able to > >> > come to Groovy and bring their preferred styles with them" is the > weakest argument ever. > >> > > >> > Do we really think any kind of developer moving from a language to > another language wants to keep writing code with the keywords of their > first language? > >> > > >> > To have the Groovy compiler compile Java code is an issue, to promote > the use of not-idiomatic coding practices is a completely different one. > >> > > >> > I think we are falling in love with the idea that a Java developer > wants to move to Groovy because the Groovy compiler compiles Java code. To > me this is a disfunctional interpretation of the reality. Unfortunately we > don't have data to support any opinion about that. > >> > > >> > I don't really think any Java developer would feel better with Groovy > because they can use `var` insted of `def` when all the Internet, > documentation, examples, stack overflow issues and everything, basically, > use `def`. > >> > > >> > And they will use `def` in any case to indicate that they want to > return `Object` from a method (so why should one use two different keywords > that are the same in variable definiton but not the same in method > definition?!) > >> > > >> > And you say that Groovy users are smart enough? With such arguments? > >> > > >> > I don't think so. > >> > > >> > Cheers, > >> > Gianluca > >> > > >> > Gianluca Sartori > >> > -- > >> > Cell. +39 388 1026822 > >> > > >> > > >> > On Thu, 28 Nov 2024 at 21:47, Paul King <pa...@asert.com.au> wrote: > >> >> > >> >> Java didn't use the term "keyword" but chose "reserved type" since > >> >> generally you can't use keywords in most other places in your code, > >> >> but for backwards compatibility you can still have "var" as a > variable > >> >> name. > >> >> Groovy also lets you have var as a variable name as well as lets you > >> >> have keywords in certain places: > >> >> > >> >> var var = [def: 1, as: 2, in: 3, trait: 4] > >> >> > >> >> You are certainly within your rights to not like "var" and think of > it > >> >> as a cross language copy-n-paste hack, but Groovy generally tries to > >> >> stay agnostic on such matters. Groovy users are smart enough to be > >> >> able to decide whether they want OO/functional, static/dynamic > typing, > >> >> var/def, closures/lambdas, etc. We want Java developers to be able to > >> >> come to Groovy and bring their preferred styles with them. Of course, > >> >> you can write a codenarc rule that flags "var" usage with warnings if > >> >> you particularly don't want "var" style in your codebases. > >> >> > >> >> Cheers, Paul. > >> >> > >> >> On Wed, Nov 27, 2024 at 8:35 PM Gianluca Sartori < > g.sart...@gmail.com> wrote: > >> >> > > >> >> > > >> >> >> 'var' support [..] slightly more flexible > >> >> >> than Java but definitely not use var (short for variable) for > methods. > >> >> > > >> >> > > >> >> > You say it is "short for variable" (like in "define a variable?") > but the documentation says it is "short for Object". It says it is a "Type > Placeholder". > >> >> > > >> >> > This is confusing because neither Java nor Groovy have a specific > keyword to define variables. > >> >> > > >> >> > In both languages variables are defined by preposing a Type before > the variable name. > >> >> > In both languages methods are defined by preposing a Type before > the method name. > >> >> > > >> >> > So if `var` is to be a Type Placeholder it should be valid in all > contexts where a Type is valid, so everywhere `def` is valid. > >> >> > > >> >> > Now, I understand it may not be immediate to use `var` in front of > a method definition but if it is documented as a Type Placeholder then > that's the way our mind will look at it. > >> >> > > >> >> > I never saw `def` as something else than a keyword in Python, > because in the docs they say it is a keyword. > >> >> > I never saw `def` as a keyboard in Groovy because in the docs they > say it is a type placeholder equivalent to Object. > >> >> > > >> >> > I think it is a mistake for Groovy to document `var` the way it is > documented today. Because it is suggesting people to use it, but it is not > a core Groovy feature, it is not idiomatic Groovy, it is a marginal > addition that exists just to make a compiler happy when copy-pasting Java > code. It should not be mentioned in the docs along with `def`. It should be > documented in a separate chapter "Java source code compatibility"or > something like that. > >> >> > > >> >> > Cheers, > >> >> > Gianluca > >> >> > > >> >> > > >> >> >> > >> >> >> Cheers, Paul. > >> >> >> > >> >> >> On Wed, Nov 27, 2024 at 4:46 AM Gianluca Sartori < > g.sart...@gmail.com> wrote: > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >> For me, def == var, in my mental model. Which means == Object. > >> >> >> > > >> >> >> > > >> >> >> > This is how I was looking at it since that’s how it has been > documented, but it has not been implemented that way. > >> >> >> > > >> >> >> > At this point of the discussion I understood it is a > documentation issue, but still something in my mind is telling me we should > have def == var. > >> >> >> > > >> >> >> > It would be groovier! > >> >> >> > > >> >> >> > Cheers, > >> >> >> > Gianluca > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >> On Tue, Nov 26, 2024 at 5:08 PM MG <mg...@arscreat.com> wrote: > >> >> >> >>> > >> >> >> >>> Hi Rémi, > >> >> >> >>> > >> >> >> >>> yes, I saw that, thank you. > >> >> >> >>> > >> >> >> >>> Most of the examples seemed obvious to me, and the bugs that > could be introduced feel like they are a little bit on the artficial side. > >> >> >> >>> > >> >> >> >>> But, having said that: Inferring an interface type or a less > specific parent type in some cases could imho be a very Groovy thing: > >> >> >> >>> > >> >> >> >>> e.g. inferring List<T> instead of ArrayList<T> > >> >> >> >>> Potentially through some explicit construct, such as "var>" > to indicate that a more loose / interface type shall be used. > >> >> >> >>> > >> >> >> >>> Not that I see any of that becoming a reality anywhere in the > near future... ;-) > >> >> >> >>> > >> >> >> >>> Cheers, mg > >> >> >> >>> > >> >> >> >>> PS: I googled a bit, and I could not find in general that ppl > think var > >> >> >> >>> in Java is something you should avoid. Instead, as with any > language > >> >> >> >>> feature, one can over-/abuse it, thereby making code less > readable than > >> >> >> >>> when using explicit types. > >> >> >> >>> It is funny thinking about this in the context of Groovy, > where > >> >> >> >>> typically ppl who use it as a scripting language do not even > use final > >> >> >> >>> instead of def when defining variables, even though they will > never > >> >> >> >>> reassign said variable 99% of the time... ;-) > >> >> >> >>> > >> >> >> >>> There is an official guide that explains some of the gotchas > >> >> >> >>> https://openjdk.org/projects/amber/guides/lvti-style-guide > >> >> >> >>> > >> >> >> >>> regards, > >> >> >> >>> Rémi > >> >> >> >>> > >> >> >> >> > >> >> >> >> > >> >> >> >> -- > >> >> >> >> Guillaume Laforge > >> >> >> >> Apache Groovy committer > >> >> >> >> Developer Advocate @ Google Cloud > >> >> >> >> > >> >> >> >> Blog: glaforge.dev > >> >> >> >> Twitter: @glaforge > >> >> >> >> Mastodon: @glafo...@uwyn.net >
