Simplifying 'value' and 'identity'
Dan Smith
daniel.smith at oracle.com
Fri Dec 15 21:22:04 UTC 2023
Two more notes, just to keep all of these ideas in one place:
> On Dec 15, 2023, at 12:22 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>
> Abstract classes: an abstract class is also an identity class by default, but may use the 'value' modifier to indicate that it doesn't require identity.
> What do we lose?
> - You can't force an abstract class/interface to be implemented by *only* value classes
> - You can't force an interface to be implemented by *only* identity classes
> - You can't declare an abstract class or interface whose type will refuse to support the 'synchronized' keyword
Another noteworthy difference is that stateless abstract classes must *explicitly* opt in to supporting value classes, whereas before we were doing so implicitly.
This is really an orthogonal choice. If we wanted to, we could roll back this aspect of the change by continuing to infer that certain abstract classes are value-compatible (in this case, that amounts to inferring the 'value' keyword).
But I've come around to the idea that a simple "all classes are identity by default" rule is good, and that the binary compatibility commitment associated with "value" (e.g., the class will never add a mutable field) is better stated explicitly.
> (For awhile, I was considering keeping around the 'identity' keyword, just for the purpose of interfaces. But, eh, nobody is going to use it.)
One problem I noticed with a two-state interfaces approach is that interfaces need to be "value interfaces" by default, but we probably don't want to allow a "value interface" to extend an "identity interface", because in this iteration 'value' is an assertion about supertypes. (In contrast to the 3-state case, where it was fine to allow an "unconstrained interface" to extend an "identity interface".)
Implication: if I'm going to add the 'identity' modifier to my interface, I first have to be sure that any subinterfaces out there are also 'identity' interfaces. But if the interface is public, how could I be sure? And if the interface is not public, what is the point of applying the 'identity' constraint at all?
Essentially, this version of 'identity interface' would only be useful for newly-declared interfaces.
More information about the valhalla-spec-experts
mailing list