RFR: JEP 360: Sealed Types (Preview)

[Vicente Romero]

Hi Alex,

Thanks for your review, some comments below

On 4/13/20 2:22 PM, Alex Buckley wrote:
>
> // amber-dev only; don't see the need to cross-post to compiler-dev
>
> On 4/13/2020 9:03 AM, Vicente Romero wrote:
>> Before we were planning to infer finality, sealness or non-sealness 
>> in the subtypes. We steered away from that direction in favor of 
>> explicit declaration at the subtype. I would like to ask for another 
>> review of the current version of the JEP that reflects these
>> changes.
>
> I think the message of this important JEP is about halfway there. I'm
> going to provide comments in email rather than actioning them directly,
> because I want to spur discussion on "why" not "what" or "how".
>
> - 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.

> is
> responsible for implementing the type." I'm borrowing the i-word from
> the introduction of JLS 6.6.2, which is superb despite its subsections
> being mind-bending. I'm also previewing the theme in the Motivation
> about helping implementors, not users (and thus the idea of
> implementation code being different than user code). BTW, you'll see
> later that I generally prefer "class or interface" to "type", but it
> would be confusing to say "class or interface" and then only say
> "implementing" (would look like we forgot "extending").
>
> - 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.

> but mostly because it inverts responsibility: the
> _implementations_ are on the hook to lock down the hierarchy, not the
> superclass who desires the restriction. Since the implementations are
> necessarily public, if any one of them gets it wrong (forgets to be
> `final`) then all the others who got it right are undermined. There is
> no _documented_ exhaustiveness (no list of subtypes) and no _actual_
> exhaustiveness (anyone can now extend the public non-final 
> implementation).
>

Thanks,
Vicente