+1
Gianluca Sartori
--
https://dueuno.com
On Sun, 15 Jun 2025 at 12:43, James Daugherty
wrote:
>
> Hi Everyone,
>
>
> The Apache Grails podling has voted to approve the release of Apache Grails
> (incubating) Plugins - Spring Security 7.0.0-M4 & Redis 5.0.0-M4. We
🎉🎉🎉
Gianluca Sartori
--
https://dueuno.com
On Thu, 12 Jun 2025 at 02:36, James Daugherty wrote:
> The Apache Grails (incubating) community is pleased to announce the
> release of Apache Grails (incubating) 7.0.0-M4.
>
> Grails is a powerful Groovy-based web application frame
+1
Gianluca Sartori
--
https://dueuno.com
On Sat, 31 May 2025 at 09:37, Paul King wrote:
>
> Hi folks,
>
> We have a feature request, and potential PR, to add java.time.* as a
> new default import:
>
> https://issues.apache.org/jira/browse/GROOVY-11513
> https://githu
a Groovy thing or it lies somewhere else?
Cheers,
Gianluca Sartori
Not sure if being in the mailing list is enough for voting but here is my
+1 :)
Gianluca Sartori
--
Cell. +39 388 1026822
On Tue, 21 Jan 2025 at 21:45, Paul King wrote:
> Hi folks,
>
> The Grails project is keen to join the ASF. The suggested path into
> the ASF is for Groovy t
Love it
Gianluca Sartori
--
Cell. +39 388 1026822
On Wed, 11 Dec 2024 at 02:33, Paul King wrote:
> I created this pull request which clarifies things somewhat:
>
> https://github.com/apache/groovy/pull/2133
>
> But feel free to create an alternative if you think it can be imp
>
> I might be wrong and I might have misunderstood something of importance,
> but it seems to me there is one (and only one) very specific need to use
> *var*: ensuring a code copy/pasted from Java works (with as little number
> of problems as reasonably possible).
>
This is what I understood as
>
> I would just start with point 1 and do one topic area at a time.
Agree
> I can't help but think some topics are subjective and fall into the
> beauty (Groovy idiomatic) is in the eye of the beholder.
>
Okay, but the point here is "aesthetic over logic". The use of "var", as of
today, falls
vy
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 wrote:
> Hi Gianluca and Paul,
>
>1. having thought about this some more, to explain Java
>
>
> In our projects, we have style checks that suggest "for (x in y) ..." over
> "for (T x : y) ...". The "in" form is groovy idiom and the ":" form is for
> java compat. Switching to use "y.each { x-> ... }" or "y.forEach(x ->
> ...)" is a personal preference. Note: the debugger steps through t
> For one, I would argue that the native and groovier (since more logical
> and intuitive and intention-revealing for anyone who can read English
> completely regardless whether he knows Java or not) variant should be the
> *for/in* loop, like *for (foo in foos)*. That weird and unintuitive colon
>
native" 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,
> &
th 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
> wrote:
> >
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 wrote:
> Java didn't use the term "keyword" but chose "reserved type" since
> generally you can't use k
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
> wrote:
> >
> >
> >
> >> For me, def == var, in my mental
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 m
went berserk, so if you want to have a laugh here it
is, take it with a grain of salt, you may come out with some info or at
least get entertained a bit :))
https://github.com/orgs/grails/discussions/13842
Cheers,
Gianluca
>
>1.
>
> Cheers,
> mg
>
>
> On 26/11/2024 1
>
> I have the feeling that your confusion comes from the fact that you think
> Groovy = Python in the Java world, and Python def = Java var, therefore
> Groovy var should be def.
>
Well, my confusion comes from the documentation (
https://groovy-lang.org/semantics.html#_variable_definition) that
>
> if you have code like this:
>
> def m(int i) {
>return i+1
> }
>
> Here you know i is an int, and then you can do a guarded version of
> static compilation that avoids all the boxing and dynamic method calls.
> This is then quite a bit faster on early executions. We used this before
> invok
e
inference where var is used.
What use cases require type inference in Groovy? Would it be useful only
when coupled with @CompileStatic? Are there use cases where it is useful
also with @CompileDynamic?
Cheers,
Gianluca
Gianluca Sartori
--
Cell. +39 388 1026822
On Sat, 23 Nov 2024 at 21:27
f`?
These are just ideas, but please correct me if the reasoning is wrong,
cheers,
Gianluca
Gianluca Sartori
--
Cell. +39 388 1026822
On Sat, 23 Nov 2024 at 04:12, MG wrote:
>
>1. Groovy has been a hybrid dynamic & static language for a long time:
>
> https://docs.g
ces that Java defines. But we have not implemented the type
> inference that Java provides; STC gives a close approximation.
>
> So if you can use var for field/property, I would consider deprecating and
> later removing that. It may not have been intentional since the grammar
> shares rules for fields and
sound a bit manipulative and maybe it is but
it genuinely is my thought)
Gianluca Sartori
--
Cell. +39 388 1026822
On Thu, 21 Nov 2024 at 22:06, Milles, Eric (TR Technology) via dev <
dev@groovy.apache.org> wrote:
> When support for var was installed, the path taken was to make it work
s not
Java" and instead of talking about "semantics" we may talk about "lexicon'
when discussing about `def` (Python lexicon) and `var` (Java lexicon) but
the semantics remains the same: they are both "type placeholders" in Groovy.
Gianluca Sartori
--
Cell. +39 38
fine a variable with `var` when you
don't care about the type of the value. Define a method return type as
`var` when you don't care about the returning value type"
Gianluca Sartori
--
Cell. +39 388 1026822
On Thu, 21 Nov 2024 at 18:10, Milles, Eric (TR Technology) via dev &l
t;the Python-ish way" we use `def`, if we want to write
code "the Java-ish way" we use `var`.
Gianluca Sartori
--
Cell. +39 388 1026822
On Thu, 21 Nov 2024 at 20:48, Jonathan Carter
wrote:
> The Oracle docs on var
> <https://docs.oracle.com/en/java/javase/17/language/l
Java supports `var` only for local variable declarations when it can infer
the type from the expression on the right side of '='
Gianluca Sartori
--
Cell. +39 388 1026822
On Thu, 21 Nov 2024 at 19:17, Steve Etchelecu
wrote:
> I thought Gianluca made an excellent argument and he
Well, actually that's not true, Groovy supports creating fields and
properties as well with `var`, so basically everything `def` does
except return types.
Gianluca Sartori
--
Cell. +39 388 1026822
On Thu, 21 Nov 2024 at 17:41, Daniel Sun wrote:
> Hi Gianluca,
>
> `var` was
Hello everybody,
My name is Gianluca Sartori, from Italy, I am the author of the open source
project Dueuno Elements (https://github.com/dueuno-projects/dueuno-elements)
and I am new to this list.
I would like to start using the more Java-ish `var` instead of the
Python-ish `def` lexicon but I
29 matches
Mail list logo
