> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@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:fo...@univ-mlv.fr | >> fo...@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
