> As we briefly talk last Wednesday, i believe there is a less disruptive way
> to add IdentityObject in the language.
>
> Let see if we can do better, there are three reasons to have IdentityObject
> (and InlineObject)
> - documentation (support for javadoc)
> - bound for generic type parameter
(or type for regular parameter)
> The only way to solve the point 2 is to have a different view at compile time
> and at runtime.
> For that,
> - the compiler should see IdentityObject as a valid super type of every
> identity classes.
> - the compiler erase IdentityObject to java.lang.Object (in particular,
> IdentityObject.newIdentityObject() return type is erased to Object).
It is tempting to erase IdentityObject to Object, but then:
Object o = new Point(0,0);
if (o instanceof IdentityObject)
sync(o) { … }
If we erase IdentityObject to Object, then we cannot do the runtime test
accurately. I suspect that 99+% of the cases where someone is locking on an
inline class (or something to be migrated to an inline class) is doing it
behind Object or behind a type variable (which is the same thing.)
> If IdentityObject is erased to Object,
… and we lose the ability to do runtime checks.
Here’s another place where this erasure game is painful:
void m(Object o) { … }
void m(IdentityObject o) { … }
So, reframing:
- IF we are willing to give up runtime checks and overloading, THEN we can
erase InlineObject to Object, because the remaining users are merely about
things like type bounds, which can be checked at compile time and erased.
So you are basically asking: how important are these things, and are they worth
injecting the extra interface?
