On 10.03.2018 03:51, Paul King wrote:
Hi, sorry I meant to respond to the list too. Messages included below.
---------- Forwarded message ----------
From: *MG* <mg...@arscreat.com <mailto:mg...@arscreat.com>>
Date: Sat, Mar 10, 2018 at 7:19 AM
Subject: Re: About supporting `var` of Java10+
To: pa...@asert.com.au <mailto:pa...@asert.com.au>
[...]
# Intersection types are especially difficult to map to a
supertype—they're not ordered, so one element of the intersection is not
inherently "better" than the others. The stable choice for a supertype
is the lub of all the elements, but that will often be Object or
something equally unhelpful. So we allow them.
I have never used intersection types. I would really be interested to
know how many people have ever used them.
I tried the following in Groovy, but got a
if you have for example this:
def x
if (b) {
x = y;
} else {
x = z;
}
x.foo()
then what is the type for x, to check if foo() is an allowed method? The
answer in Groovy is, it is the LUB(type(z),type(y)). The result might be
an intersection type for x, that for example consists of Object and all
interfaces the two have in common.
[...]
# Anonymous class types cannot be named, but they're easily
understood—they're just classes. Allowing variables to have anonymous
class types introduces a useful shorthand for declaring a singleton
instance of a local class. We allow them.
How do you assign a new value to a variable that has a type that exists
only once:
In Java with var you don´t
[...]
Maybe I am overlooking something, but using the anonymous type here
looks like it would effectively make the variable final. So it looks
like using the non-anonymous super class might make more sense here (it
would not break Java compatibility, and would give programmers more
options, if final is also changed in Groovy to use the RHS type instead
of Object).
I can do
var x = new Object() {
public void foo(){}
};
x.foo();
Using Object for x, does no longer allow you to call foo(). The only
variant this can be made work in Java right now is by not using an
anonymous inner class. This here is the "declaring a singleton instance
of a local class" that is intended to be allowed.
So some of the simple immediate implications are:
* error if var used for fields
As I said supporting that would feel Groovy to me, so if it is easy to
do I would support it, but I don't see it as essential in any way.
In a field declaration like "var x = 1" we can do it. We cannot do it
for the anonymous inner class, if we are supposed to take the specific
class. We cannot do it for intersection like types, because we need a
real type to give to the field. We cannot do it if the initialization is
in more than one place (multiple constructor for example) and probably a
few more. I would definitely go without this first.
[...]
The devil will be in the detail when we try to update the type checker
I assume the replacement
var x = RHS
becoming
typeof(RHS) x = RHS
cannot be done before the type checker runs ?
nope
- and for dynamic Groovy I suspect we might need some additional
restrictions in addition to those chosen by Java.
Stupid question: Why ?-)
Isn't the dynamic case just
1) var -> typeof(RHS)
2) done
?
I think for dynamic Groovy we should do var == def. we cannot do var ->
typeof(RHS), because we may not know the RHS type at compile time. And
at runtime the RHS type is really not of that much use anymore.
But for me that means the more restricted one is var in static
compilation, not dynamic.
bye Jochen
