Lifting the restriction on the number of public classes per file
Remi Forax
forax at univ-mlv.fr
Mon Nov 26 22:03:43 UTC 2018
> De: "Kevin Bourrillion" <kevinb at google.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Lundi 26 Novembre 2018 20:43:37
> Objet: Re: Lifting the restriction on the number of public classes per file
> Sorry for delay. Can we unpack the "for whatever reason" part? For what reason?
> Unsurprisingly to anyone, we actually hard-ban this practice here. Multiple
> top-level classes per file just make code harder to find; what are the
> advantages?
There are two kind of nesting,
- nesting for scoping, like with inner classes
- nesting for sealing, like we are part of the same hierarchy.
We don't want sealing to imply scoping.
One solution is to allow multiple public top level classes as Brian propose, the other solution is to allow sealing without scoping with by example a keyword.
We can introduce a new keyword (let's call it 'whatever') which means this is a subtype and a nestmate but not an inner class,
sealed interface Expr {
whatever record Add(Expr left, Expr right);
whatever record Value(int value);
}
>From outside Expr.java, Add and Value are toplevel classes that can be used like this:
Expr expr = new Add(new Value(3), new Value(39));
should work.
Rémi
> On Mon, Nov 12, 2018 at 8:35 AM Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] > wrote:
>> This was received through amber-spec-comments.
>> I agree with the general sentiment, especially for sealed types, where we want
>> to define an entire sealed type hierarchy in a single compilation unit (but for
>> whatever reason, prefer not to nest the subtypes in the super type.) There are
>> some details to be worked out (e.g., use of the SourceFile attribute by tools).
>>> Begin forwarded message:
>>> From: Francois Green < [ mailto:francois.green at gmail.com |
>>> francois.green at gmail.com ] >
>>> Subject: Lifting the restriction on the number of public classes per file
>>> Date: November 11, 2018 at 10:09:06 PM GMT+1
>>> To: [ mailto:amber-spec-comments at openjdk.java.net |
>>> amber-spec-comments at openjdk.java.net ]
>>> In the face of the changes in code style that records will bring about, has
>>> there been renewed discussion about lifting the restriction?
>>> public interface Blue;
>>> public record IKB() implements Blue;
>>> public record Azure() implements Blue;
>>> public record Royal() implements Blue;
>>> Having to place each line in the code above in its own file seems harsh.
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kevinb at google.com |
> kevinb at google.com ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181126/5b0da513/attachment.html>
More information about the amber-spec-experts
mailing list