On 08.03.2018 14:13, Paul King wrote:

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


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


Reply via email to