groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Fwd: About supporting `var` of Java10+
Date Sat, 10 Mar 2018 13:23:31 GMT
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* <mgbiz@arscreat.com <mailto:mgbiz@arscreat.com>>
> Date: Sat, Mar 10, 2018 at 7:19 AM
> Subject: Re: About supporting `var` of Java10+
> To: paulk@asert.com.au <mailto:paulk@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

Mime
View raw message