Sealed types -- updated proposal

[Kevin Bourrillion]

Question about option #3: would it make only direct subtypes of the
sealed/switched-on type available in this way, or recursively?

I agree with limiting the options to #1 and #3. Between the two of them,
I'm a bit on the fence. This is a good feature for enums, and this case is
mostly similar, but not entirely; the chance for ambiguous simple names
changes a few things. For example, when I add a new subtype to a sealed
type that shares its simple name with an existing subtype, I've broken
calling code that wasn't qualifying. Also just the need for users to choose
whether to qualify or not is a pain.

However, it is nice that it doesn't "make you" import the type which makes
that simple name usable in the entire file including in places where its
meaning would be less clear.

Meh?



On Fri, Feb 1, 2019 at 9:59 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> > On Jan 31, 2019, at 4:07 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> >
> > You have forgotten that
> > - if you have a sealed class (not sealed interface), using nesting has
> the side effect of creating inner classes.
>
> Kind of a strange way to put it. I would put it as: “the user has the
> option of nesting both static and non-static classes, as is appropriate to
> the situation.”
>
> And, nested records — the likely common case — will be implicitly static.
>
> > - for #4, I've proposed a simple scheme that allow tools to find the
> compilation unit of any auxiliary classes of a sealed type.
>
> Everything is possible.  But, it’s a question of cost vs benefit.  I have
> come around to thinking this is a bigger hammer than the value of the
> benefit.  And further, a rule like “it would only be allowed for subtypes
> of a main sealed type” is a pretty serious design smell.  If we’re going to
> do this, it should be all or nothing, standing on its own, but there is
> limited appetite for this.
>
> Aligning the treatment with enums — which is the other source of
> exhaustiveness constraints in the language — is a much cleaner move.
>
> For libraries like the JDK, we’ll almost surely bite the bullet and split
> into separate source files.  This is an acceptable “tax” for the JDK; we
> pay taxes like this all the time.  There’s a range of other tradeoffs users
> can make.
>
>
>

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190201/23bd73d6/attachment.html>