> De: "Kevin Bourrillion" <kev...@google.com>
> À: "Brian Goetz" <brian.go...@oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts@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.go...@oracle.com
> |
> brian.go...@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.gr...@gmail.com |
>>> francois.gr...@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-comme...@openjdk.java.net |
>>> amber-spec-comme...@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:kev...@google.com |
> kev...@google.com ]
