Received on the -comments list.
My analysis: while the package { ... } syntax acts as a nice container
for multiple class units, and might well have been a nicer syntax for
multiple classes in the same source file than aux classes, it's really
no different than allowing aux classes to be public; we are still left
with the same problem of finding the source file corresponding to
com/foo/X.class, because it will not necessarily be the corresponding
com/foo/X.java in the source path.
-------- Forwarded Message --------
Subject: nest syntax alternative
Date: Fri, 15 Feb 2019 13:19:00 +0100
From: Maarten Van Puymbroeck <[email protected]>
To: [email protected]
Hello,
Just thinking out loud here.
Remi's proposals about the nest syntax and flattening of nested subtypes
gave me the idea of "package files".
This would allow all classes of a package to be defined in one file instead
of a directory, making them implicitly part of the same nest without the
nested class issue (if it's considered an issue). The concept would be
compiled away completely.
shedding a bike:
package com.test.expressions {
sealed class Expr {}
record Value(int value) extends Expr;
record Add(Expr left, Expr right) extends Expr;
}
Apart from the choice of nest host, this probably has other concerns. But
maybe the idea might spark some other ideas...
Kind regards,
Maarten.
(just a silent follower)
