groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: About supporting `var` of Java10+
Date Fri, 09 Mar 2018 00:39:28 GMT


On 08.03.2018 14:13, Paul King wrote:
>
> On Thu, Mar 8, 2018 at 9:53 PM, mg <mgbiz@arscreat.com 
> <mailto:mgbiz@arscreat.com>> wrote:
>
>
>     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:

<zip>


> 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.

I see that argument in general, but here it seems to be mostly that 
"var" is allowed in more places than "def" - would that really lead to 
an explosion of complexity ?
Also would those differences not also exist in the var === def case ?

> 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).

Not true, shown by the examples in my last mail, which is completely 
dynamic Groovy: Assignment fails during runtime in var-equivalent-case, 
and works in def-case.

> 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)

The flow typing cannot deduce what is not expressed, in this case the 
type we want a variable to be restricted to. So var and flow typing are 
orthogonal concepts.

> The argument on the flip side is fairly simple too. We have two names, 
> we can use those to
> represent two different concepts.

One of them being exactly the concept Java uses, the other a much more 
lenient concept coming from the dynamic part of the Groovy world.

> 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"

Yes, def can be used to fake var, but it is not var.
By the same argument you could ask, why Groovy supports much more 
complex (to implement and maintain) concepts such @CompileStatic and 
flow typing, when everything works exactly the same as in the dynamic 
case (i.e. dynamic Groovy code looks like static Groovy code or Java - 
but the underlying semantics are different).

In the end it boils down to: var === def would keep Groovy look and feel 
like Java, while var with Java-like semantics would do that _and_ extend 
the possibilities of Groovy developers to more easily express 
themselves. That "more" comes at a price, in current and future 
development efforts, just as any other language feature...

To me, coming more from a non-def-using, type-safe, easier-to-read-code 
perspective, I feel like it is a wasted opportunity, now that a var 
keyword is being introduced, because once var === def has been coosen, 
changing its semantics to Java-like later on would be a breaking change, 
and will therefore most likely not happen. So for all the Groovy 
developers that see Groovy as a fully blown, mostly statically typed 
language, I would ask you to reconsider :-)

mg







Mime
View raw message