[Sorry disregard last content-free message. Still getting used to a new
mail client.]
On 26 Jan 2022, at 7:42, Dan Smith wrote:
If we do not use interfaces, the runtime class of java.lang.Object can
be Object, being an identity class or not is a just a bit in the
reified class, not a compile time property, there is contamination by
inheritance.
Object can't be an identity class, at compile time or run time,
because some subclasses of Object are value classes.
That’s true, but stripping away the marker interfaces removes (one
part of) the contract that a class, as a whole, must always accurately
report whether *all its instances* have one or the other property, of
having identity or having no identity.
As I said in an earlier meeting, there are sometimes reasons to give
*the same class* both value instances and identity instances. Yes this
muddies the user model but it also helps us with compatibility moves
that are required, however much they muddy the user mode. (Actually all
exact instances of `Object` will be identity objects. I’m thinking of
`Integer` which might want mostly values but some identity objects for
backward compatibility. Maybe.)
Independently of that, for the specific case of `Object`, having a query
function `Class.instanceKind`, which returns “NONE” for abstracts
else “VALUE” or “IDENTITY”, would encode the same information we
are looking at with those marker interfaces. But the contract for a
method is *more flexible* than the contract of a marker interface.
In particular, `instanceKind` is not required to report the same thing
for T and U when T<:U but marker interfaces are forced to be consistent
across T<:U. I think this is an advantage, precisely because it has
more flexible structure, for the method rather than the marker
interface.
If the marker interfaces also have little use as textual types (e.g.,
for bounds and method parameters) then I agree with Remi. Ditch ‘em.
