> I have had more than 100 (maybe more than 200) Java folks tell me that > they like > Groovy because it lets them bring their Java style with them.
I am not going into a "mine is bigger than your discussion", what I know for sure is that when you learn a new language you go through the "Quick Start" guide at least, and try to understand what the language has to offer instead of expecting the language to accept what you are used to. Anyway... If you feel the documentation can be improved, please submit a PR. > I'd like to contribute, but before submitting a PR I want to reach an agreement on what to do, I don't want to spend my time on something just to have my work rejected because of arbitrary arguments with no real data to support them. How are decision taken in the Groovy team? Who do I have to convince to have a "Similarities with Java" chapter and put there all the features you call "Java Compatibility" and remove every reference to those features from every other place in the docs? 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 >
