RFR: JEP 360: Sealed Types (Preview)

[Vicente Romero]

Hi Alex,

Thanks again for your comments, I have tried to cover all we have 
discussed, I hope the topics have been blended smoothly,

Vicente

On 4/13/20 9:09 PM, Alex Buckley wrote:
> 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