On Nov 19, 2021, at 5:32 AM, Brian Goetz <brian.go...@oracle.com<mailto:brian.go...@oracle.com>> wrote:
And this is not inconsistent with abstract superclasses contributing fields. For me the poster child is Enum as much as Record. I want pure enums, some day, but in order to make this work we need a way for the ordinal and name fields to (a) appear in the abstract class Enum and (b) be suitably defined in the layout of each Enum subclass, whether it is an identity subclass or a pure (B2) subclass. Sketch of an example way forward (but still with the sense that we have more important things to do): - Allow fields to be marked abstract, and mark Enum’s fields that way. - Do not require (or allow) constructors to initialize abstract fields. - The JVM can support virtualized getfield, maybe, or just ask the T.S. to use access methods. - As with methods, require a concrete subclass to redeclare inherited abstracts. - The concrete subclass will naturally declare and initialize the now-concrete field. - Have Enum support both kinds of constructors: Old School (fully concrete) and empty. - Figure out some story for concretifying Enum’s fields for Old School clients. The trick would be to configure Enum so that it was a fully functional super for both kinds of subclasses; it should behave one way to Old School enum subclasses and another way to B2 enum subclasses. It’s a research project. I get the sense there’s a path forward, but not a simple one. If you exclude fields, then it’s not as hard as a research project IMO. The abstract supers of a B2 are not themselves B2; they are polymorphic types that (conventionally) live in the Old Bucket.
