On 11.03.2018 17:29, MG wrote:
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...
the difference is that it is not supposed to do that in static mode ;)
[...]
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.
Integer foo(int i) {1}
String foo(String s) {"2"}
def bar (x) {
return foo(x)
}
at the callsite in bar you cannot tell if foo(int) or foo(String) is
supposed to be called. Methods at runtime increase the problem, but it
is not unique to them. And it does not always have to be an override in
the classic sense either
[...]
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)
}
ah, I was talking about local variables, not about fields/properties.
For me that style is more the exception. And once you move the code to
the constructor you do not get inference for the field/property anymore.
So its good only for some very specific cases. And for those to make a
difference in the dynamic mode...
bye Jochen
