> From: "Kevin Bourrillion" <kev...@google.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Brian Goetz" <brian.go...@oracle.com>, "Dan Heidinga" > <heidi...@redhat.com>, "valhalla-spec-experts" > <valhalla-spec-experts@openjdk.java.net> > Sent: Thursday, April 28, 2022 3:51:07 PM > Subject: Re: [External] : Re: User model stacking
> On Thu, Apr 28, 2022 at 9:09 AM Remi Forax < [ mailto:fo...@univ-mlv.fr | > fo...@univ-mlv.fr ] > wrote: >>> So we’re suggesting restacking towards: >>> - Value classes are those without identity >>> - Value classes can be atomic or non-atomic, the default is atomic (safe by >>> default) >>> - Value classes can further opt into having a "val" projection (name TBD, >>> val is >>> probably not it) >>> - Val projections are non-nullable, zero-default — this is the only >>> difference >>> - Both the ref and val projections inherit the atomicity constraints of the >>> class, making atomicity mostly orthogonal to ref/val/zero/null >> Now that the model is clearer, let's try to discuss about the val projection. > (For the record, I don't think the messages of the last 48 hours have made the > model "clearer", just floated a lot of possibilities.) It's clearer to me, the properties of the value types whatever the way we decide to group them are runtime property, not type property. Using a L-type instead of a Q-type just add null into the set of possible values. > But I do want to say I appreciate you providing all these opposing arguments > to > my proposal (which I asked for!). > I'm going to engage with your specific arguments, but I don't recall if you > ever > engaged properly with all of mine. I feel like if you took them into account > also, your overall position might be more balanced? In particular, it is a > *huge* simplification to be able to say that every class does the exact same > thing, and some just do extra. [...] See my answers to Brian. >> 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. > You have to opt into a class being subclassable, then you have to opt into > subclassing it. > There's tons of examples. subclasseable and subclassing are not the same property. Here we are talking about zero-default and zero-default. zero-default value class Complex { ... } // opt-in here class Holder { Complex.val x; // and opt-in here } You need both otherwise it's not zero-default. > I'm not sure that's a good framing anyway. The use-site doesn't really opt in > or > out. The class just opts in to generating two types. Now there are two types > and clients use those types however they want. >> 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. > People can come back and purchase that better performance for the price of > dealing with the safety hazards. imho, this is exactly as it should be. This is only true if you control the whole code, otherwise you are using a library and the .val that is missing is inside the library. > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | [ > mailto:kev...@google.com | > kev...@google.com ] Rémi
