EG meeting, 2021-11-17

[Dan Heidinga]

I'll echo Brian's comment that I'd like to understand Kevin's use
cases better to see if there's something we're missing in the design /
a major use case that isn't being addressed that will cause useer
confusion / pain.


That said....

> 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.

This is the same list (+synch) as I listed earlier and we've
previously talked about.  It sounds like we're on the same page here.

>
> 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.

... and with this complex translation strategy we bring in a whole new
set of issues with compatibility of programs as they evolve,
especially across maintenance domains.  That convenient supertype adds
a new abstract field?  Or changes its field initialization logic?  Or
.... any number of new scenarios that break compatibility that we
won't find out until later (See the user surprise around new default
methods to I causing ICCE in clients now seeing two candidates for the
same method due to multiple inheritance of the method from other
interfaces the client implements).

 I’d rather leave it for later; we
> have so many more worthwhile things to do.
>

+1.

--Dan