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 13:13:41 GMT
On Thu, Mar 8, 2018 at 9:53 PM, mg <mgbiz@arscreat.com> wrote:

> Hi Paul,
>
> I would be interested to hear if you see some advantages of going down the
> #define var def
> route - apart from the obvious, that it is the easiest/fastest to
> implement ?
>

I am not too worried about ease/speed of implementation but I think we have
to be on a continual quest for simplification.
So for "def"/"var" if we just decide things organically as we go we might
end up with numerous differences:
* one is a keyword, one is a reserved type name
* one is allowed as a variable name, the other not
* one is allowed to declare methods, the other not
* one is allowed for class names, the other not
* one is allowed for package names, the other not
* one is allowed as a direct key for a map, the other not
and so forth.
And then that complexity travels throughout the code base multiplying
against the other orthogonal axes where differences occur.
Before we know it we can end up with an explosion of complexity that has to
be maintained.

But also, if we want to make Groovy Java "var" friendly, what simple
explanation can we give
knowing that Groovy is a different language to Java?
For dynamic Groovy, it can't really mean much different to "def"
(effectively Object).
Java is introducing "var" it to reduce ceremony for local variables, i.e.
maximise type inferencing.
However, that is what we already do (albeit backed by a flow typing
semantics different to Java)
when we use "def" and @CompileStatic or @TypeChecked. So, I can see good
points for just making
one an alias of the other. It would mean allowing a few ugly corner cases
like "def def" (currently not
allowed) and "var var" but you could check against such cases with a
Codenarc rule. And as it turns
out, isn't too much to implement.

The argument on the flip side is fairly simple too. We have two names, we
can use those to
represent two different concepts. Even Java considered different names:
let, val, auto, const, or final, instead of or in conjunction with var. But
given what they have
decided - a semantics very close to our "def" - I can't see what difference
we can now make
of the other name - apart from the obvious difference of limiting it to
places where Java
would use it, i.e. limit it to just local vars and perhaps just within
@CompileStatic annotated
nodes. But I don't see any value in those limitations.

Cheers, Paul.


> -------- Urspr√ľngliche Nachricht --------
> Von: Paul King <paulk@asert.com.au>
> Datum: 08.03.18 12:26 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: Re: About supporting `var` of Java10+
>
> What are peoples thoughts. Should we try to make "def" and "var" exactly
> aliases? Or almost?
> If we do, we need to add some info in the differences from Java section of
> the doco to explain the differences with Java's upcoming "var".
> If we don't, we need to articulate some good reasons for making the
> distinction.
> I am leaning slightly towards the former but I can see arguments for both
> sides. In any case I am interested in others thoughts.
> At a minimum, I'd like to see both ""def" and "var" recognised as reserved
> type names in the grammar rather than keywords.
> Any thoughts?
>
>
> Cheers, Paul.
>
>
> On Thu, Mar 8, 2018 at 7:57 PM, Jochen Theodorou <blackdrag@gmx.org>
> wrote:
>
>>
>>
>> Am 08.03.2018 um 09:44 schrieb mg:
>>
>>> @unless you reassign, you would not notice the difference between current
>>> def and the Java var:
>>> 1) If I don't need to reassign, I would use final instead of var :-)
>>> 2) Supporting var for fields that get initialized during declaration,
>>> also would feel very Groovy to me, although I personally would not expect
>>> to use that a lot.
>>>
>>
>> they decided against using final and instead go with semi-final.
>>
>> bye Jochen
>>
>
>

Mime
View raw message