Sealed types -- updated proposal

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 1 Février 2019 15:57:11
> Objet: Re: Sealed types -- updated proposal

>> On Jan 31, 2019, at 4:07 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> 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.”

Forgetting 'static' is a very very common mistake. that's why i'm sensitive over that issue. 
And the resulting class is a non-sense, it's a class that inherits from a super class and delegate to the same super class. 

> And, nested records — the likely common case — will be implicitly static.

yes, you're right. As a user, you still have the nasty surprise when you refactor a record to a class (to add a field by example). 

I think there is a common ground here, we can disallow sealed classes. 
I will avoid user to fell into the inner class trap and we can allow them later if we were overly cautious. 

>> - 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.

yes, i agree, it's not perfect. 

> Aligning the treatment with enums — which is the other source of exhaustiveness
> constraints in the language — is a much cleaner move.

it's another clue that we should not allow sealed classes, enums like interfaces define a static context unlike classes. 

> 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.

Rémi