IdentityObject & abstract superclasses

[Peter Levart]

I apologize for not reading the previous discussion about "Superclasses 
of inline classes" (as of 19th of dec. 2019). I now see the intent was 
to not use a special class modifier to express the feature of light 
abstract class.

The intent was also to allow extending "light" abstract classes with 
inline as well as non-inline classes. In that case, a modifier like 
"inline" would be a strange way to express such thing.


Regards, Peter


On 8/26/20 11:01 PM, Peter Levart wrote:
> Hi,
>
>
> Perhaps I missed some previous discussion about this, but I can't 
> quite understand why a decision whether an abstract class is "light" 
> or "heavy" and consequently doesn't implement IdentityObject or does 
> implement, has to be implicit. Couldn't it be explicit like it is for 
> concrete classes? Couldn't the language allow saying:
>
>
> public abstract inline class SuperInline {
>
>     // no instance fields allowed, no constructors allowed
>
> }
>
>
> vs.:
>
>
> public abstract class SuperIdentity {
>
>     // everything allowed (but nothing required), implicitly 
> implements IdentityObject
>
> }
>
>
> A concrete or abstract inline class could only extend abstract inline 
> class.
>
> A concrete or abstract non-inline class could only extend concrete or 
> abstract non-inline class.
>
>
> With such explicitness about the intent (inline vs. non-inline) there 
> would be less unintentional surprises.
>
>
> What do you think?
>
>
> Regards, Peter
>
>
> On 8/18/20 1:44 AM, Dan Smith wrote:
>> There's an interesting interaction between IdentityObject and 
>> abstract superclasses of inline classes that might be worth leaning 
>> into.
>>
>> ---
>>
>> The "status quo" (inasmuch as one exists):
>>
>> An inline class can extend a class if it, and all of its supers, 1) 
>> are abstract, 2) declare no instance fields, and 3) have "empty" 
>> <init> methods. These properties represent a new kind of abstract 
>> class—call it a "light" abstract class. Changing a "light" abstract 
>> class to be "heavy" is a binary incompatible change.
>>
>> Separately, we have the IdentityObject interface, which is implicitly 
>> attached to all non-inline concrete classes. An abstract class might 
>> also be able to implement IdentityObject explicitly, and doing so 
>> would also disqualify it from being an inline class super.
>>
>> A struggle in this story is getting programmers to care about whether 
>> their classes are "heavy" or "light", since even though it's an 
>> important property, it's easy to overlook (there's no syntax for it, 
>> and in many cases, there are no immediate effects).
>>
>> ---
>>
>> Alternative story:
>>
>> An inline class must not extend IdentityObject through any of its 
>> superclasses. (That's it.)
>>
>> A non-inline class implicitly implements IdentityObject if it 1) is 
>> concrete, 2) declares an instance field, or 3) has a non-empty <init> 
>> method. Abstract classes can also explicitly implement IdentityObject.
>>
>> Changing a class so that it implements IdentityObject is a binary 
>> incompatible change.
>>
>> Now we have a highly-visible concept (IdentityObject) that 
>> programmers should generally be aware of anyway, and they should 
>> readily understand a difference between abstract classes that 
>> implement IdentityObject and those that don't.
>>
>> ---
>>
>> I think I like the alternative story. It feels simpler.
>>
>> One reason to avoid it is if we think there's potentially value in a 
>> "light" abstract class concept that is independent of IdentityObject. 
>> For example, maybe some other feature could build on the idea of a 
>> superclass that requires no initialization, without tying that to the 
>> topic of object identity. I'm having trouble envisioning a use case, 
>> though. Another reason to avoid it is if we want IdentityObject to be 
>> limited to concrete classes—no explicit implementing it allowed.
>>
>> If the alternative story is the one we want, it implies that the 
>> "empty <init>" JVM feature should be part of Inline Classes, not a 
>> separate thing we deliver earlier—because it's directly tied to 
>> IdentityObject.
>>