Alternative to IdentityObject & ValueObject interfaces

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "daniel smith" <daniel.smith at oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Sent: Thursday, March 24, 2022 1:46:44 PM
> Subject: Re: Alternative to IdentityObject & ValueObject interfaces

> On 3/23/2022 10:51 PM, Dan Smith wrote:

>>> On Mar 22, 2022, at 5:56 PM, Dan Smith < [ mailto:daniel.smith at oracle.com |
>>> daniel.smith at oracle.com ] > wrote:

>>> - Variable types: I don't see a good way to get the equivalent of an
>>> 'IdentityObject' type. It would involve tracking the 'identity' property
>>> through the whole type system, which seems like a huge burden for the
>>> occasional "I'm not sure you can lock on that" error message. So we'd probably
>>> need to be okay letting that go. Fortunately, I'm not sure it's a great
>>> loss—lots of code today seems happy using 'Object' when it means, informally,
>>> "object that I've created for the sole purpose of locking".

>>> - Type variable bounds: this one seems more achievable, by using the 'value' and
>>> 'identity' keywords to indicate a new kind of bounds check ('<identity T
>>> extends Runnable>'). Again, it's added complexity, but it's more localized. We
>>> should think more about the use cases, and decide if it passes the cost/benefit
>>> analysis. If not, nothing else depends on this, so it could be dropped. (Or
>>> left to a future, more general feature?)

>> Per today's discussion, this part seems to be the central question: how much
>> value can we expect to get out of compile-time checking?

> This is indeed the question. There's both a "theory" and a "practice" aspect,
> too.

>> The type system is going to have three kinds of types:
>> - types that guarantee identity objects
>> - types that guarantee value objects
>> - types that include both kinds of objects

>> That third kind are a problem: we can specify checks with false positives
>> (programmer knows the operation is safe, compiler complains anyway) or false
>> negatives (operation isn't safe, but the compiler lets it go).

> Flowing {Value,Identity}Object property is likely to require shoring up
> intersection types too, since we can express Runnable&IdentityObject as a type
> bound, but not as a denotable type. Var helps a little here but ultimately this
> is a hole through which information will drain.

> The arguments you make here are compelling to me, that while it might work in
> theory, in practice there are too many holes:

> - Legacy code that already deals in Object / interfaces and is not going to
> change
> - Even in new code, I suspect people will continue to do so, because as you say,
> it is tedious for marginal value
> - The lack of intersection types will make it worse
> - Because of the above, many of the errors would be more like warnings, making
> it even weaker

> All of this sounds like a recipe for "new complexity that almost no one will
> actually use."

I agree, 
so if we drop the idea of having identity vs value info into the type system, the follow-up question is "should we restrict inheritance or not ?" 

Classes are tagged with value or not, and for an abstract class or an interface by default they allow both value types or identity types as subtypes. 
Do we need more, i.e. be able to restrict subtypes of an abstract class/interface to be value types (or identity types) only ? 

Yesterday, Dan S. talk about a user being able to restrict a hierarchy to be identity classes only. This will not help already existing codes but may help new codes by instead of having IdentityObject in the JDK, let a user define his own interface that play the same role as IdentityObject but tailored to his problem ? Or do we consider that even that use case does not worth it's own weight ? 

Rémi