Hi Gianluca,
On 25/11/2024 13:48, Gianluca Sartori wrote:
I am trying to understand if it makes sense to implement type
inference (both variables and methods?) when using @CompileStatic
instead of when using `var`. Because at that point the developer is
declaring he wants type checking and all the compile time checks &
performance improvements.
This is incorrect, as I have already pointed out: Groovy is /not /an
untyped language, as is e.g. Python. As soon as you use a type other
than Object (= def) in a variable declaration, Groovy will check that a
value assigned to said variable is of a compatible type.
See "Apache Groovy is a powerful, /optionally typed/ and dynamic
language, with static-typing and static compilation capabilities..."
(https://groovy-lang.org/#:~:text=Apache%20Groovy%20is%20a%20powerful,and%20easy%20to%20learn%20syntax.)
https://www.luisllamas.es/en/typed-vs-untyped-languages/#:~:text=On%20the%20other%20hand%2C%20untyped,Let's%20see%20some%20examples.
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.
Those assumptions are incorrect:
1. Python is untyped, Groovy optionally typed.
2. Java is not a dynamic language, therefore Java var is used to
statically infer the type of a variable, not to declare an untyped
variable (i.e. a variable of type Object).
1. Note that var x; is not supported in Java, even though it could
be argued x should be of type Object in that case, precisely for
that reason.
3. And of course: Jython is Python in the Java world ;-)
This way we could use `def` or `var` and they could be the same (with
type inference working on `def` too).
Changing the semantics of def to use type inference instead of being an
alias for the Object type would be a collosal breaking change, so
besides being not what def is for in Groovy, it would be impossible for
all practical purposes.
I don't know, I am trying to simplify things instead of adding `var`
to the language not because we need it but just to allow the
copy-paste from Java. We have `var` because of Java? Okay, but let it
be a first citizen instead of just a token to digest with no errors.
There are tons of constructs Groovy supports for the sole reason to be
as copy & paste compatible with Java as possible (Java-style
curly-braces literal arrays, Java for-each loops, etc, etc), and none of
these are first class citizens / idiomatic Groovy.
The var reserved word, that as a technicality is currently mapped to def
with some restrictions, is just a small blip in a large sea here.
In general, please reread all my previous replies, I am pretty sure I
have already answered all other questions/points you keep bringing up,
in some cases with sample code... :-)
Cheers,
mg
