I think what dan is saying is that you are positing a degree of freedoms that is unnecessary. We want to have abs classes that can be a base for both inline and idents. An abstract ctor can be the indicator of this. But, why bother with allowing such a class to extend one that doesn’t meet the same requirements? They will be useless for in lines anyway. Require that the ctors be “abstract all the way up.”
Sent from my iPad > On Feb 9, 2020, at 1:08 AM, John Rose <[email protected]> wrote: > >> On Feb 8, 2020, at 9:08 PM, Dan Smith <[email protected]> wrote: >> >> Oh, yeah, if we need to make sure that code gets executed (for identity >> classes), that will affect the design. > > That’s the root of the stuff you found perhaps unnecessary. > It could be done the way you propose also, but adding the > ability of the invokespecial to turn into a “pop”, and dealing > with the loss of Object::<init> as a handy point of reference, > makes for a different, less regular set of JVM changes. > > I could go either way on having Object::<init> changed to > be abstract, but I think it’s safer to leave it exactly as is, > and then just say “inlines never get there”. > > — John
