----- Mail original -----
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net>
> Envoyé: Vendredi 6 Décembre 2019 22:04:08
> Objet: Re: IdentityObject and InlineObject
>> 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.
you can:
Object o = new Point(0,0);
if (!(o instanceof InlineObject))
sync((IdentityObject)o) { … }
>
> Here’s another place where this erasure game is painful:
>
> void m(Object o) { … }
> void m(IdentityObject o) { … }
You see it as painful, i see it as a feature, it means that i can replace
Object by IdentityObject and still be binary backward compatible.
And this example is not a good one because introducing overloads that have a
subtyping relationship is hard to get right. You may not have the same behavior
depending if something is typed as Object or as IdentityObject even if it's the
same class at runtime. Not the kind of code you want to use.
>
> 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.
No, if you willing to remain binary backward compatible with existing code when
you introduce IdentityObject, then it should be erased.
>
> So you are basically asking: how important are these things, and are they
> worth
> injecting the extra interface?
No, injecting is fun but I value binary backward compatibility more.
Rémi
