RFR: JEP 360: Sealed Types (Preview)

[Alex Buckley]

On 4/13/2020 5:24 PM, Vicente Romero wrote:
> On 4/13/20 2:22 PM, Alex Buckley wrote:
>> - Goals and Non-Goals are meant to precede Motivation. This helps to
>> ensure that the Goals are not simply a restatement of the problem (from
>> the Motivation) or the solution (from the Description). Currently, the
>> Goals (well, Goal) is more or less the solution. I think the first goal
>> should be "Allow the author of a type to control which code
> 
> I trust you here. I would have preferred saying: which `subtype` or 
> `subclass` is responsible for extending the type. For example an 
> interface listed in a permits clause of a sealed interface doesn't 
> necessarily have to provide any implementation of the sealed 
> superinterface. And after all what are listed in a permits clause are 
> classes and interfaces which is something more explicit than `code`. 
> Still I modified the JEP as you suggested.

Good, thanks. I understand what you're saying, but in this very first, 
most high level, goal of the entire project, it's fine to generalize; to 
focus on only critical cases; and to not enumerate all the subthings.

>> - The JEP says "Access control allows the library author to constrain
>> which packages can access and therefore implement the library, but
>> ***cannot distinguish an implementor from a user***." First, I can't
>> tell what the library author is meant to be doing -- please show me.
>> Second, the starred text is not the fully story: the traditional way to
>> restrict an implementation hierarchy is for the restrictive superclass
>> to be package-private (AbstractStringBuilder) while the implementations
>> are co-located in the same package and final and public (StringBuilder +
>> StringBuffer). Please spell out and slam this scheme in the Motivation
>> as being hard to maintain -- partly because it fails to enumerate the
>> implementations, 
> 
> I believe that sealed types fixes the first issue: it is possible now to 
> enumerate the implementations but still the implementations are the ones 
> that lock down the hierarchy. Enumerating a subtype doesn't allow the 
> superclass to state: and it has to be final or else. It is still the 
> responsibility of the implementation to lock down the hierarchy. So IMO 
> the motivation shouldn't pretend to fix an issue that is left basically 
> in the same state that it is now.

This is a fair point. Two points in response: (1) The Motivation should 
still highlight Java's erstwhile lack of capability by incorporating two 
examples (one showing the library author doing with access control 
whatever it is the JEP has been claiming they can do, and another 
showing the AbstractStringBuilder example); (2) The Motivation should 
follow up by saying that polymorphism -- the degree to which objects are 
substitutable -- is traditionally a joint venture between the superclass 
and the subclasses, and that it is Good and Right and Principled that a 
superclass can't force its subclasses to constrain themselves as, say, 
`final` classes [YOU KNOW AND I KNOW THAT WE ALSO MEAN "SEALED CLASSES", 
BUT DON'T TELL THE READER THAT], and that doing better on the 
enumeration front would make Java code more maintainable (more capture 
of intent, more predictability of hierarchy, safer switch, etc) while 
preserving that long-held principle. "In other words, we aim to give 
more power to the superclass author without taking away any power from 
the subclass author."

Alex