I went to improve the documentation and found that "var == Object" is
only in the variable definition section which, although no doubt could
be improved, does seem correct.
The fact that it works for property/field definitions (though not
property accessor methods) is in part, as Eric mentioned, because of
some shared grammar, but it wasn't accidental, more a case of allowing
what could be useful cases.
E.g. consider an expression like:
var foo = 'bar'
in a script. Such a definition normally gets inserted into the run
method and becomes a local variable definition but with Groovy's
JEP-445 support, if you add an instance main method:
def main(args) { println foo.toUpperCase() }
It now becomes a field. It seems like a useful feature to support this
form for folks porting scripts over to use JEP-445 but no doubt the
usefulness of such a feature is open for debate. This particular case
wasn't applicable when 'var' support was added but various cases like
this were discussed and the decision was to be slightly more flexible
than Java but definitely not use var (short for variable) for methods.
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
