Sealed types -- updated proposal
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Feb 1 16:57:55 UTC 2019
> 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
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.
More information about the amber-spec-observers