The reality is we are evolving our perspective as we gain experience with the model. Once we prove out that we have something that actually works, There will be a round of updating the terminology.
Sent from my iPad > On Jul 10, 2020, at 8:54 AM, Remi Forax <[email protected]> wrote: > > From valhalla-spec-observers, > > ----- Mail original ----- >> De: "Gernot Neppert" <[email protected]> >> À: "Valhalla Expert Group Observers" >> <[email protected]> >> Envoyé: Vendredi 10 Juillet 2020 12:06:32 >> Objet: Clarification needed about primitive wrappers? > >> Hello, >> >> it seems some clarification is needed about the fate of the primitive >> wrappers in "Valhalla-world". >> In this and the related Mailing Lists, you can find the following two >> proposals, with subtle differences: >> >> 1. the primitive wrappers (java.lang.Integer etc) are designated to become >> inline classes. This idea has been most recently cited in the posting >> "Identity warnings for inline class candidates". >> >> 2. the primitive wrappers should become the reference-projections of >> corresponding inline classes. This has sometimes been augmented with the >> idea that the denominations for the primitive types (such as "int") will >> then become aliases for those new inline types. >> >> So, what's it going to be? > > The idea is to retrofit primitive types to be inline types, at the Java > language level, not at the VM level. > Once you have to done, given that a wrapper type is a way to transform a > primitive type to an object, > a wrapper type is the reference projection of the corresponding primitive > type (which is now an inline type). > > [...] > >> >> But then, if we are going with proposal 2, what would be so special about >> the reference-projections of the primitive types? Shouldn't all reference >> projects be treated equally? > > nothing special, it's more than the semantics of Integer now and the > semantics of Integer being the reference projection of int are slightly > different. > >> Wouldn't it mean that synchronizing on an IdentityObject obtained via >> reference-projection should always warrant a warning? > > the reference projection is a projection not a boxing, so at runtime, the > reference projection of an inline type is still an inline type, so a > reference projection can not be an instance of IdentityObject. > >> >> It may well be that all this is perfectly clear to you experts, however, it >> might still be advantageous to use consistent wording everywhere! > > I'm not sure it's perfectly clear even to us :) > > Rémi >
