groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: Possible New Groovy Features... - var Keyword
Date Sun, 27 Aug 2017 02:41:10 GMT
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 
> 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.


View raw message