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