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.
