[External] : Re: Possible refinement for sealed classes

[Brian Goetz]

>
>     Essentially, I want to put the `permits` list on Sandwich, and
>     have `WithCheese` and friends delegate their permits to
>     `Sandwich`, rather than having each interface enumerate their
>     subtypes.
>
>
> I'm not sure to understand why this case is special enough to get a 
> special way of delegating the "sealness" (the fact to be sealed, i 
> don't know if there is a term in English for that) apart that it would 
> be cool to have it.

The tradeoff of sealing is that you have to maintain an explicit list of 
permitted subtypes (unless you're lucky enough that your whole hierarchy 
fits in one file.)  That's fine, but if you program in the Sandwich 
style outlined in this thread (which is a reasonable style for modeling 
some domains), you end up having to write O(n) permits lists, and keep 
them in sync.  This is annoying for both code writers and readers; 
gunking up the declaration of WithCheese (which is a pretty abstract 
concept) with a list of concrete cheese-bearing sandwiches feels out of 
place.

>
> Delegating the "sealness" in that direction, from an interface which 
> subtypes are subtypes to the sealed type, seems less readable that the 
> other direction, from the sealed type to the interface that will have 
> subtypes that implement the sealed type.

Sure, there's other ways to paint the shed, but the concept here is: 
WithCheese only makes sense in the context of Sandwich (according to 
this sandwich restaurant.)  This is the concept we're trying to capture; 
it could be at the declaration of the interface, or at the declaration 
of Sandwich.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210401/0549fd8c/attachment-0001.htm>