> '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 >
