> De: "Brian Goetz" <[email protected]>
> À: "Remi Forax" <[email protected]>, "Gavin Bierman"
> <[email protected]>
> Cc: "amber-spec-experts" <[email protected]>
> 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
