So let me recap:
1. Groovy syntax in main documentation + Java compatible syntax in side
notes
2. A "Groovy for Java developers" chapter that collects all Java
compatible syntax and code styling
3. A "Groovy for Groovy developers" chapter that collects all Groovy
best practices
Could this be the structure of the Groovy documentation and a goal to reach
in 2025?
Gianluca Sartori
--
Cell. +39 388 1026822
On Wed, 4 Dec 2024 at 16:11, MG <mg...@arscreat.com> wrote:
> Hi Gianluca and Paul,
>
> 1. having thought about this some more, to explain Java
> constructs/syntax in side notes seems like a good approach :-)
> 1. Initially I was for collecting this information in a seperate
> chapter.
> 2. But this would not work well for all cases, because some
> off-meta language constructs can have their merits in some cases, and so
> should be explained together with native Groovy concepts.
> 1. e.g. using a for(foo : foos) { ... } loop instead of
> canonical Groovy foos.each { foo -> ... }, to be able to easily
> return from
> the for body from multiple places using return statements.
> 3. It also could lead to people thinking that Groovy does not
> support a certain syntax which they are used to, when in fact it does.
> 1. If you are in the "let's have have a quick look here" phase
> of evaluating a language, this can imho turn away people pretty
> quickly.
> 2. In addition, having an (extended) "Java constructs in Groovy"
> (o.s.) chapter might still also be a good idea.
> 1. Imho it could just explains a little bit of the general
> background of:
> 1. Groovy aiming for Java copy-and-paste compatibility where
> possible.
> 2. Java compatibility vs canonical Groovy.
> 3. Examples for caveats where Groovy matches Java syntax, but *not
> *Java semantics (e.g. var).
> 4. etc
> 2. ...and for details refer to the Java side notes in specific
> chapters.
> 3. On the inverse side of that, giving information in the side
> notes (and/or a sperate chapter) about what would be considered canonical
> Groovy, best practice, or what is general a powerful way of using Groovy in
> certain scenarios, might also be beneficial.
> 1. e.g. that using dynamic Groovy together with @TypeChecked:
> 1. Is fast (because, generally speaking, dynamic Groovy is fast).
> 2. Gives the same level of rigid code checking static
> compilation in Java supplies.
> 1. Or can even go beyond that.
> 3. While still supporting e.g. dynamic call site resolution,
> which allows for the very simple & elegant addition of handling of
> newly
> introduced sub classes in method calls, without changing any of the
> calling
> code or resorting to a if(foo instanceof FooChild) { ... } cascades
> G-)
>
> Cheers,
> mg
>
>
> On 04/12/2024 11:02, Gianluca Sartori wrote:
>
> > 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
>>
>
>
