groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Fwd: About supporting `var` of Java10+
Date Sun, 11 Mar 2018 13:58:09 GMT
On 10.03.2018 20:33, MG wrote:
> Hi Jochen,
> I was not aware that Groovy is so sophisticated in its expression 
> analysis, that it actually uses intersection types

you actually do not have much of a choice. It is an AST-only 
representation only though.

>  3. It would, on the other hand, allow to introduce var support not
>     based on var === def to dynamic Groovy later on, without breaking
>     backwards compatibility (becauseĀ  var x = new Foo(); x = 123
>     suddenly does not work any more)

what exactly is the advantage of not having var === def? Only to 
disallow the reassignment in some cases at runtime? I do not see much 
gain in that actually

> Just food for thought - I personally would prefer to see the "90% 
> solution" I talked about in an earlier post for dynamic Groovy:
> Support var x = RHS -> typeof(RHS) x = RHS for simple cases, such as:
> var x = new Foo(...)
> var x = (Foo) ...
> var x = foo(...) // use the explicit return type of method foo(), CTE on 
> return type == def ("'var' not supported for 'def' as return type - use 
> Object as return type of method or define variable using 'def'.")
> throw CTE in all other cases (least surprise - "'Type for variable 
> defined with 'var' cannot be deduced in dynamic Groovy. Annotate the 
> method/class with @CompileStatic to switch to static compilation, or 
> replace 'var' with 'def'."

there is almost no expressions consisting of multiple expression, that 
we can tell the type of in dynamic mode. Even something simple as 1+1 
can in theory return a ComplexNumber suddenly.

>  From the view of my framework code that goes even more so for the 
> related case of final x = RHS -> final typeof(RHS) x = RHS I therefore 
> keep going on about - if dynamic Groovy does not pick up the RHS type 
> for final, I need to keep my current code, or force framework users to 
> use @CompileStatic on all Table derived classes, if they want to define 
> table columns in the most elegant and concise way... :-)

for "final x = ..." the exact type of x is in dynamic mode actually 
totally not relevant. There is no reassignment, so that problem is out 
here. But if we forget about that, then there is no difference between 
"final x" and "def x". I know cases where it could make a difference, 
but they do not exist in Groovy yet. so what exactly is final x supposed 
to do different than def x besides the reassignment?

bye Jochen

View raw message