Refinements for sealed types
brian.goetz at oracle.com
Sun Aug 18 19:25:28 UTC 2019
> So if everything is explicit, we want
> - all sealed types to defines their permit clauses
> (so we need a kind of "permit none" if no subtypes is allowed ?)
> - all subtypes of a seal types to explicitly says if there are sealed or non sealed (to avoid accidental unsealing).
> am i right, or am i missing something ?
Yes, this is basically it. I don’t think we need “permits none” because a sealed type with no permitted subtypes is effectively a final type, and only makes sense for concrete classes, so that’s a final class.
> There are several ways to reduce the ceremony
> - implicit declaration of sealed subtypes if the super type is sealed
> - implicit declaration of permit clauses
> and we may want to choose one, the other or both.
Right. Now, some observations:
- We have two cases (sum types, and restricted hierarchies), and two goals (ceremony management, and safety/clarity);
- Implicit sealing of subtypes by default serves both goals and both use cases, but asymmetrically; it provides ceremony reduction for the sum types case, and safety for the restricted hierarchy case.
- Ceremony reduction is far more important for the “sum types” use case than for the “restricted hierarchy” use case, for several reasons.
- Implicit declaration of permits clauses provides ceremony reduction for the sum types case.
- Both forms of ceremony reduction start to cross over into being liabilities for the restricted-hierarchy case, because readers should have full information about the hierarchy shape.
- Most sum types will be co-declared; many restricted hierarchies will not be.
So, given all this, we should focus all our ceremony-reduction on the case of co-declared sum types. Which is mostly what I think I was suggesting:
- Infer the permits clause when all the subtypes are co-declared;
- Infer “final” for leaf classes in a sum type;
- Require explicitness in both sealed/non-sealed, and permits clause, in other cases.
We could tighten this further, which probably makes sense:
- Infer the permits clause when the subtypes are co-declared;
- Infer final _when the current class is a subtype of a sealed type in the same compilation unit, and has no subtypes_ (again, co-declared with its parent);
- Require explicit sealed or non-sealed in all other cases;
- Require explicit permits clause in all other cases.
So this focuses the magic on co-declared hierarchies.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts