Sealed types

[Brian Goetz]

> 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

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181207/14b7e11a/attachment.html>