> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Samedi 26 Janvier 2019 17:08:51 > Objet: Re: nest syntax proposal
> Let’s back up and look at the problem, before we jump to solutions. > The sealed class mechanism, on its own, is fine. I think we have the right > knobs > to express the sorts of types we want. > People are going to want to express sums of records. And they are going to > want > to do so “conveniently.” There are several inconveniences: > - Defining a sum of five records in a flat namespace requires six files, all > of > which may frequently be one-liners. This is annoying to write, but it is also > harder to read — if these classes are so tightly related, we want to declare > them in one place. > - The streamlined syntax (inferring the permits clause) is clearly aimed at > supporting the above (many languages with sealed types don’t even let you > declare subtypes outside of the same compilation unit.) It is better for > readers and writers for simple subtypes of simple sealed types to be defined > together. > - We could define them as auxiliary classes, and everything would be great, > except aux classes can’t be public. (Accidental interaction number 1.) > - We could define them as nested classes, and everything would be great, > except > then clients have to deal with the nesting. (Accidental interaction number 2.) We can have multiple public classes in case there is a sealed type by lifting the restriction, force to have the compilation unit to have the same name as the interface and make all subtypes nestmate of the interface. For tools, it means that if you want to find the java file from a class file, if there is not corresponding java file, then you can look in the java file of the nest host of the class file. > If we don’t solve this problem at all, what are people most likely going to > do? > Most of the time, I suspect non-API writers will write nested records, and > then > use import static to hide the nesting from the client view. which is fine with sealed interface not sealed class ... > And API writers will bite the bullet and use six files. > Neither of these are terrible, but they have that whiff of friction that we > know > people will complain about, because they don’t like their choices. But I think > we could ship the feature with no special support in any case. So we’re in the > “filing rough edges” department. I think we can lift the "only one public class" if the compilation unit is the sealed type as described above because it's a backward compatible change. It doesn't solve the case you want several record classes with no sealed type, but at least we cover the most common case. Rémi >> On Jan 26, 2019, at 8:24 AM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] >> wrote: >> I've slept on that problem this night. >> Let's focus first on the sealed type, You are proposing to declare the >> subtypes >> inside the sealed type, so you get nesting automatically and you can use >> import >> + a special switch rules to be able to reference a subtype directly. >> I believe this fell flat with a sealed class, because you are mixing >> inheritance >> and enclosing scopes. >> Let's take an example >> sealed class Expr { >> public void aMethod() { ... } >> record Value(int value) extends Expr; >> record Add(Expr left, Expr right) { >> public void anotherMethod() { >> aMethod(); // call super.aMethod() or Expr.this.aMethod() ? >> } >> } >> } >> as you can see, we are mixing inheritance and enclosing scope here, i don't >> think it's wise to let a user to write this kind of monstrosity. >> I wish inner classes where never invented (anonymous class are fine) but >> it's a >> too late ... >> We can say that records are always a static class, but refactoring a class >> to a >> record or vice-versa will create instant puzzler. >> We can only support sealed interface, not sealed class, it may be not a bad >> idea >> per itself, anyway i think we should no try to mix nesting and subtyping. >> Rémi >>> De: "Brian Goetz" < [ mailto:brian.go...@oracle.com | >>> brian.go...@oracle.com ] > >>> À: "Remi Forax" < [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] > >>> Cc: "amber-spec-experts" < [ mailto:amber-spec-experts@openjdk.java.net | >>> amber-spec-experts@openjdk.java.net ] > >>> Envoyé: Lundi 21 Janvier 2019 00:07:01 >>> Objet: Re: nest syntax proposal >>>>> And they understand auxiliary classes. Let’s work with the familiar >>>>> concepts. >>>> but your solution seems tailored to sealed types, what if i have several >>>> record >>>> classes with no common abstract type, how it works ? >>>> and again there is no refactoring between a classical interface and a >>>> sealed >>>> interface, something we should try offer. >>> Indeed, I think there are two things here. We can choose to address one or >>> both >>> or neither, with the obvious tradeoffs. >>> Issue #1 is that sealed types naturally form a family, you’re going to >>> switch >>> over them, etc, like enums, and we want the same (or more) nice treatment >>> as we >>> currently get with enums in switch. So it makes sense to define them all in >>> one >>> place; indeed, that should be the common case. Doing something with import >>> helps here, but as you say, it is more specific to sealed types. On the >>> other >>> hand, enums and sealed types are related, so mirroring the special treatment >>> that enums get (maybe even giving both a little more) is a low-energy-state >>> solution. >>> Issue #2 is that with records, one line per file starts to seem silly. This >>> has >>> a lot of overlap with #1, but not entirely. You could argue its a more >>> general >>> solution, and maybe we like that, but maybe we don’t. It surely is more >>> intrusive — affecting the existing semantics of auxiliary classes, and >>> dramatically increasing the use of auxiliary classes (which, BTW, we’ve >>> banned >>> from the JDK source base because they make life very hard for build >>> tooling), >>> etc. It’s a bigger hammer. >>> Its also possible we do nothing here, and let users nest the subtypes and >>> clients just say “import static SealedType.*”. That’s the least intrusive, >>> so >>> we should compare cost/benefit against that baseline.
