Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
Subject: Re: Possible New Groovy Features... - var Keyword
To: users@groovy.apache.org, Jochen Theodorou <blackdrag@gmx.org>
References: <6f1d6eea-3c73-1e04-61f2-7444c8fd0ce2@arscreat.com>
 <CAMbkE7RwY5MR5K3qRnYnjuLQvwXt9Gp8nO5crM6BQ6EkWof10Q@mail.gmail.com>
 <ffc6c648-2fa9-3f54-094c-3c98b8782dc2@arscreat.com>
 <9ef02e12-bff6-c132-f3ac-ce19a884e217@gmx.org>
From: MG <mgbiz@arscreat.com>
Message-ID: <33309536-027c-56be-993b-c53844d58a99@arscreat.com>
Date: Sun, 27 Aug 2017 04:41:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <9ef02e12-bff6-c132-f3ac-ce19a884e217@gmx.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
archived-at: Sun, 27 Aug 2017 02:41:24 -0000

Hi Jochen,

On 25.08.2017 10:05, Jochen Theodorou wrote:
>
>
> On 23.08.2017 00:52, MG wrote:
>> Hi Paul,
>>
>> On 21.08.2017 04:30, Paul King wrote:
>>>
>>>     Introduce a "var" (o.s.) keyword that allows deduction of type
>>>     through assignment:
>>>     var device = new PrinterDevice(...) // device variable will have
>>>     type PrinterDevice without the need to explictely state that
>>>     Rationale: This is a well known feature of other languages, that
>>>     reduces the need to explictely define the type of variables.
>>>
>>
>>> How is this different to the current type inferencing?
>>
>> The variable/field will have the type of the initally assigned value
>> (instead of Object when using def), therefore one cannot accidentially
>> assign any other type to it.
>
>
> Didn't see a further comment on this so... If you have the static 
> compilation mode we use flow typing to determine the type of the 
> variables. That means:
>
> def x = ""
>
> will make x have the type compile time type String, so that x.foo() 
> will be marked as compilation error. Flow typing means you can do this:
>
> def x = ""
> x = 1

Flow typing is cool, and I would gather much harder to implement than a 
"var" keyword (btw, I actually just used the name used by C#, even 
though picking a different name might be a better choice, to avoid 
confusion with e.g. Javascript).
I would however argue that in the majority of cases one will not want to 
assign an integer value to a "String variable", but will want to keep 
the type assigned at declaration time, so a var keyword to me is an 
orthogonal feature to flow typing.

> without getting an error. Basically you loose compile time checks on 
> assignment and gain more flexibility on the usage of the variable. But 
> since you seem to want to make everything final if possible, that 
> should not bother you too much.

Emphasis on "if possible"... :-)
Var would be for the remaining cases where variable reassignment is the 
most sensible approach.

>
> The bottom line is: var kind of the default in static compilation mode

see under "orthogonal feature" above; var would work in dynamically as 
well as statically compiled code, so it is also orthogonal in that sense.

Cheers,
Markus