groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: About supporting `var` of Java10+
Date Thu, 08 Mar 2018 23:01:50 GMT
On Fri, Mar 9, 2018 at 5:46 AM, Aarjav Patel <aarjav@semandex.net> wrote:

> Hi all,
>
> I do not know all of the intricacies in the difference between current
> groovy def and the proposed java var. However as a groovy 'user' coming
> from a Javan background, I would like or expect var in groovy to be
> treated/behave the same way as in java. def then would be an 'enhanced'
> version of var which works better (?) with other language features. This
> way there are less surprises when using var.
>

But Java doesn't have a dynamic mode so it is difficult to offer the exact
same behavior. We could prohibit "var" from being used in dynamic Groovy
but users might expect to be able to cut and paste from Java and run in
dynamic mode. So, I am suggesting that for dynamic mode that correct code
copied and pasted will run as expected and incorrect code will fail "as
expected" but at runtime. With the caveat being that Groovy does have some
other differences to Java which would come into play. This is how "def"
behaves now. Similarly, for static Groovy, I am suggesting "def" behavior.
This is slightly different to Java's behavior - the Groovy type checker
employ's flow typing which is a different approach to Java's but similar in
many situations. My suspicion is that if we write a second chunk of the
type checker with Java only semantics for "var", then in code with mixed
"var" and "def" definitions, it will become more difficult for programmers
to follow what is going on.

Unfortunately I have not looked at 2.5+ regarding lambdas. Are they just
> another way to denote a closure? Just wondering how it was handled so that
> maybe it can give us similar options for var/def.
>

The special lambda support is a 2.6/3 feature. It would be great to discuss
that further but it's not the topic here. In 2.5 there is no change to the
existing "lambda" support which essentially boils down to coercion of
Closures to SAM interfaces including all of those that underpin Java's
lambdas.


> Thanks,
>
> - Aarjav
>
> On Mar 8, 2018 8:58 AM, "mg" <mgbiz@arscreat.com> wrote:
>
>> My argument was not in relation to the JEP, but a Groovy user story, in
>> relation to you saying, that I would not see a difference between def and
>> var, apart from when assigning a value later on.
>>
>> But assigning a value later on is _exactly_ what I am going to do when I
>> use var - because otherwise I would use final instead of var...
>>
>> -------- Urspr√ľngliche Nachricht --------
>> Von: Jochen Theodorou <blackdrag@gmx.org>
>> Datum: 08.03.18 13:32 (GMT+01:00)
>> An: dev@groovy.apache.org
>> Betreff: Re: About supporting `var` of Java10+
>>
>>
>>
>> Am 08.03.2018 um 12:45 schrieb mg:
>> > Maybe I am missing your point, but what I meant was: When I use
>> >
>> > var x = new Foo()
>> >
>> > I indicate that x will be reassigned further down in the scope,
>> > otherwise I use
>> >
>> > final x = new Foo()
>>
>> That's what I understood. But the later variant is not part of the JEP.
>> In Groovy what you wrote is an alias for final Object x = new Foo()
>>
>> bye Jochen
>>
>

Mime
View raw message