IdentityObject & abstract superclasses

[Dan Smith]

> On Sep 3, 2020, at 8:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> The "lacks a no-arg ctor" is new and interesting.  I think what you're saying is that having an explicit no-arg ctor with an empty body is a more stable signal of intent than an implicit one?  I can see that.
> 
> Shouldn't the non-empty body one be "declares any constructor with a non-empty body", regardless of arity?  The only reasonable thing here would be a side-effect (like an instance initializer) or a nontrivial super call, both of which seem to put you in the Identity category.

The way I wrote these rules is confusing. Let me try again.

An inline superclass must have a constructor of the form:

Foo() { super(); }

If this constructor is implicit (because the class body declares no constructors), that's fine. I guess we could force it to be explicit, but I think the goal here is to minimize the effort an abstract class puts into authorizing inline subclasses. Support for inline subclasses is the default behavior.

If the 'super()' call in an empty no-arg constructor is implicit, that's fine.

If the class body declares *other* constructors too, that's fine. When there are multiple paths to initialize an instance, the inline subclass will always choose the "do nothing" path.

> Still not sold on keying off the existence of a constructor with a novel shape at the classfile level.  Seems too clever, and comes with a complex verification.

Yeah, I wonder if a straightforward "InlineSuperclass" attribute at the class level is a better way to encode this. John likes the idea that the class author explicitly says "there's no initialization to do", but I think it also works to specify that inline subclass creation uses a separate mechanism that simply doesn't perform initialization.