> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Dan Heidinga" <heidi...@redhat.com>, "valhalla-spec-experts" > <valhalla-spec-experts@openjdk.java.net> > Sent: Thursday, April 28, 2022 3:43:59 PM > Subject: Re: [External] : Re: User model stacking
>> On Apr 28, 2022, at 9:09 AM, Remi Forax < [ mailto:fo...@univ-mlv.fr | >> fo...@univ-mlv.fr ] > wrote: >> 1/ There is a difference between Foo and Foo.ref for generics, Foo is a class >> while Foo.ref is a type. >> The idea of using Complex.val means that the relationship is reversed, >> Complex is the type and Complex.val is the class. > This is simply wrong. > Classes and types are separate things; declaring classes gives rise to types. > The class is Complex, in both cases. In both cases, it gives rise to two > types, > which might be denoted Complex.ref and Complex.val, or one of which might be > also called Complex. But just because they have the same name, doesn’t change > what they are. Classes != types. The class is Complex. Always. it can work both way either Complex.val c = new Complex.val(); or Complex.val c = new Complex(); I've chose the former notation because in a previous message, Dan H. expected the former too. The problem with Complex.val c = new Complex(); is obviously that the class and it's corresponding time are not the same. We will have to teach everybody var in var c = new Complex(); is inferred as Complex.val and not Complex. Again, it goes a principle of least surprise, the type of new X() is X. > I think most of the other points depend on this misconception, but I’ll skip > to > …. Even if creating a Complex is done by using new Complex, you still have all same issues because the type Complex and the class Complex disagree about who they are. Let suppose we have class Holder { Complex c; } What is its default value ? One may think that it can ask reflection for it Holder.class.getField("c").getType().getDefaultValue() but it does not work because the type Complex and the class Complex disagree. >> 4/ It's a double opt-in, people have to opt-in at declaration site by asking >> for >> a zero-default value type but that is not enough, >> it only works if the type val is uses at use site. I don't know any feature >> in >> Java that requires a double opt-in. > To say “it doesn’t work” is like saying “I have a sink with hot and cold > taps, I > turned on the cold tap, and no not water came out, this sink doesn’t work.” > The > declaration site enables the existence of the hot water tap; whether you turn > it or not is your choice. > I think what 4/5 are trying to get at is “it feels like too much ceremony to > have to say something at both the declaration and use sites in order to get > full-flat vals.” > This is a valid opinion! But its also pretty obvious that this is a potential > concern, so I’m not sure what you’re getting at by raising it in this way > (supported by the preceding misguided arguments?) It's not about too much ceremony, it's about adding a construct that breaks how people think that Java or any typed languages work. Here, as a user i declare that the class Complex is zero-default but the type Complex is null-default. By example, new Complex().re == 0 is true while new Object() { Complex c; }.c.re throw a NPE. As i said, Java has no construct where you need to double opt-in. >> 5/ It's easy to forget a ".val". To work, people will have to pepper .val >> everywhere and it will be easy to miss one occurrence. >> Depending on where the ".val" is missed, performance will suffer. > I think this is your whole point: “people will have to type .val a lot, and > they > might miss one”, right? > This is exactly the sort of argument I was talking about by “let’s not try to > jump to the end and design the final syntax immediately.” As should be clear, > a > lot of thought has gone into teasing out the elements of the model; give > yourself some time to internalize them. Having Complex and Complex meaning two different things depending on if its a class or a type is something i don't want to internalize. We should keep thing simple. Rémi
