> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr>, "Gavin Bierman" > <gavin.bier...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Lundi 22 Mars 2021 15:12:58 > Objet: Re: Draft JEP: Sealed Classes
>> I think it's missing a discussion about lambdas, anonymous classes and local >> classes that can all extends/implements a sealed type. >> For Lambdas and anonymous classes, it's easy, they are anonymous, so have no >> name to list in the permits clause. > Yes, we should state these exclusions explicitly. >> For Local classes, they are not allowed because they may not be visible >> sealed interface I {} // I don't see A from here >> void foo() { >> record A() implements I {} >> } >> But i think we may want to relax that rule a little to be able to declare a >> sealed type and an interface if they are at the same "nested level" >> @Test >> void aTestMethod() { >> sealed interface I {} >> record A() implements I {} >> } >> It's very convenient when you want different hierarchies when testing things >> like reflection inside JUnit. > I'm sympathetic to these arguments, but I'm not sure this is the time to > revisit > them. Yes, we could expand the usefulness of sealed types in "local world", > but > the return-on-complexity is pretty weak. > Additionally, we've had some discussions about regularizing the rules > surrounding local classes, and these interact with some other ideas in the > pipeline. I'd rather take a note to address this when we address local classes > more comprehensively, rather than piecemeal. Ok, i don't think there is a lot of complexity here but there is clearly more complexity that just a sealed type doesn't permit local classes. >> I also think we should add a discussion about why using the keyword >> "non-sealed" >> instead of something like "open", i.e why using a hyphen separated keyword >> instead of a "grammar local" keyword, >> because it's a question often asked when i've explained that JEP. Something >> along the line that hyphen separated keywords are a lexer issue so it's less >> work for all the Java ecosystem, all the tools that parse java code, than a >> using "grammar local" keyword which requires to tweak the parser or the >> grammar >> (or both). > We should refer to: [ https://openjdk.java.net/jeps/8223002 | > https://openjdk.java.net/jeps/8223002 ] for this. Yes Rémi