Draft JEP: Sealed Classes
forax at univ-mlv.fr
forax at univ-mlv.fr
Mon Mar 22 20:26:33 UTC 2021
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Gavin Bierman" <gavin.bierman at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210322/58d60490/attachment.htm>
More information about the amber-spec-experts
mailing list