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 <http://glaforge.dev>
>> >> >> >> Twitter: @glaforge
>> >> >> >> Mastodon: @glafo...@uwyn.net
