Sealed types

[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 7 Décembre 2018 23:33:24
> Objet: Re: Sealed types

>> basically forcing me to write the code that the compiler generates for me when i
>> use an anonymous class.

> Yes, and I'm OK with that :)

> You could look at the glass as 90% full (after all, you can still do what you
> want to do), or 10% empty (you had to be more explicit about it.) I think its
> more like 90% full.

> And "explicit" is the name of the game here. If I asked 1000 Java users what
> would go wrong if there were non-denotable subtypes, how many of them do you
> think would immediately say "That would be bad for my clients, because I'm
> depriving them of exhaustive decomposition?" Any? I doubt it. Which means a lot
> of people will make the mistake of doing so without even realizing what they're
> doing. By being explicit about what the subtypes are, it is harder to make this
> mistake. That seems a reasonable tradeoff for the increased type checking.

> This "hosing the clients without realizing it" is a lot like this one:

> [
> https://stackoverflow.com/questions/23453287/why-is-final-not-allowed-in-java-8-interface-methods/23476994#23476994
> |
> https://stackoverflow.com/questions/23453287/why-is-final-not-allowed-in-java-8-interface-methods/23476994#23476994
> ]

> People wrote angry blogs about how broken Java 8 interface methods were because
> they didn't support all the modifiers that class methods did. They would
> self-righteously claim "If I make a method final, you should assume I have a
> damn good reason, and not second-guess me." It did not occur to one person
> that, if you give people the ability to make interface methods final, you might
> put your clients in a terrible (possibly impossible) situation. When people are
> writing APIs, they rarely think enough about how this interacts with other
> APIs, or client code; they're focused through the lens of their own API.
> Supporting anonymous or lambda subtypes makes it way too easy to forget that
> you're taking something important away from your clients.

> Now, you might think this feature is 95% about subclass control and 5% about
> exhaustive decomposition, and so this seems like the tail wagging the dog to
> you. But it's an opportunity for use to do better type checking -- which makes
> programs more reliable -- and I don't want to give that up so easily.

> (And, if we're wrong now, we can always relax this later, once people are more
> educated about exhaustiveness. Not so much in the other direction.)
Your argument about "hosing the clients without realizing it" already apply to sealed types. 
We are about to see angry blogs anyway, people saying that they can not add an implementation of a sealed interface thus sealed interfaces are a bad idea. 
With a sealed interface, the developer of the API claims the right to decide what are the subtypes to the detriment of the users of that interface. 

About the exhaustiveness, making a class private is enough for making the exhaustiveness to go away. I agree with you that people may shoot themselves in the foot too easily by creating a sealed hierarchy that is not exhaustive for the compiler, but the right thing is not to force subclasses to have a name but to add an annotation that verify that the exhaustiveness is guaranteed if the sealed interface is visible (subclasses has to be named *and* has to be as visible as the sealed interface) exactly like we have @FunctionalInterface. Obviously, we can have an annotation in one direction (i want exhaustiveness) or the other (i don't want exhaustiveness). 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181208/89f1b458/attachment.html>