Will imports always be necessary when pattern matching on sealed types,
or could there be something like the provision for enum switches?
We could expose a model where a sealed nest is more like an enum, and
the nest members are more like enum constants, in which case using the
same rules
On Mon, Nov 26, 2018 at 9:05 PM John Rose wrote:
> The hardest downside to the proposal is that IDEs and some javac
> compilation modes (source-paths) don't know where to look for a file
> containing pkg.A, if the classfile pkg/A.class has not yet been generated.
>
I agree, and would add that
When we have sealed classes and records, it will be practical and
sensible to declare entire related hierarchies together:
-- Shape.java
sealed interface Shape { }
record Circle(Point center, int radius) extends Shape;
record Square(Point corner, int length) extends Shape;
--
Not
On 27/11/2018 02:04, John Rose wrote:
In source code the simple names can be obtained by using an import
which mentions NH: `` import pkg.NH.* ``. So there's no great
source-level
advantage to having the top-level names (package members) instead
of the nested names (class members). Maybe
> De: "John Rose"
> À: "Kevin Bourrillion"
> Cc: "amber-spec-experts"
> Envoyé: Mardi 27 Novembre 2018 03:04:01
> Objet: Re: Lifting the restriction on the number of public classes per file
> On Nov 26, 2018, at 11:43 AM, Kevin Bourrillion < [ mailto:kev...@google.com |
> kev...@google.com ] >
On Nov 26, 2018, at 11:43 AM, Kevin Bourrillion wrote:
>
> Multiple top-level classes per file just make code harder to find; what are
> the advantages?
I suppose the main advantage (as suggested in the examples) would be
flexibility of naming. With inner classes your names are
> De: "Kevin Bourrillion"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> 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
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
