On Nov 18, 2021, at 2:58 PM, Remi Forax <fo...@univ-mlv.fr<mailto:fo...@univ-mlv.fr>> wrote:
I suppose you are talking about empty (no field) abstract classes. We need that for j.l.Object, j.l.Number or j.l.Record. From a user POV, it's not very different from an interface with default methods. Yes. The key thing is that the abstract class in question does not accidentally entangle itself with object identity. There are three ways off the top of my head to do that: - have a constructor that needs to write fields through `this` - have a mutable instance field - have synchronization somewhere (a synch. method) We’ll need to have a way for an abstract class (for Record, for example) to stand clear of the object identity thicket. I think we could allow such an abstract class to have final fields, with suitable restrictions. But it would require a complex translation strategy and/or tricky JVM support. The problem is that the fields in the super would have to be replicated into each concrete subclass in a physically separate manner. Also the fields would have to have their initialization declared by the superclass but defined by the concrete subclass. Also field access might need to be virtualized, if each concrete subclass has its own idea about where the field “lives” in its bundle of fields. It’s doable but messy. I’d rather leave it for later; we have so many more worthwhile things to do.
