groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Fwd: About supporting `var` of Java10+
Date Sun, 11 Mar 2018 16:29:39 GMT


On 11.03.2018 14:58, Jochen Theodorou wrote:
> 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.

What I meant was: Since Groovy is for instance still using dynamic call 
site resolution in @CompileStatic mode (see: Minecraft obfuscation 
problem), it might conceivably also fall back to Object & dynamic 
resolution in such cases...

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

Disallow and document for anyone reading the code, yes (always the same 
argument).

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

We already touched on that topic in the past: I still think that allowing
new Foo()
or
Foo myFoo(...)
to return anything that is not of type Foo is "too flexible", and 
therefore should be disallowed, or fail.

Afaics Intellisense also operates on the assumption that types given are 
honored in dynamic Grooy.

>
> [...]
>>  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?

class Foo {
     final f0 = new FoorchterlichLongerNome(...) // class field c0 will 
have type Object; when analyzing the class using reflection, field 
cannot be found by looking for fields/properties of type Col
     final FoorchterlichLongerNome f1 = new FoorchterlichLongerNome(...) 
// class field will be of type FoorchterlichLongerNome; this is the 
behavior I would wish for without explicitely being required to give 
FoorchterlichLongerNome , even in the dynamic case, for simple 
expressions (as listed above)
}

I totally understand if you do not agree with me - maybe there is 
nothing here but to agree to differ...
mg




Mime
View raw message