----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com>, > "valhalla-spec-experts" > <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mercredi 1 Mai 2019 16:12:05 > Objet: Re: Is V? what we need ?
>>> Boxes are not a good thing; they were a necessarily evil that arises from >>> the >>> fact that primitives are not objects. But they create many problems of >>> their >>> own. I don’t see how “more boxes” is the answer here. >> >> More boxes is a temporary answer until we have fully reified generics >> because at >> that point we have generics over value types. > > I agree that we need a plan for how to both be stable in the short term and > long > term. But I think “temporary” is a fantasy! Whatever we add now, is part of > Java forever. So we should add the types that make sense both now and later. I fully agree, it's like getting ride of Integer, it's a fantasy, but not having a lot of API taking a N? as parameter type make that fantasy actually possible for the libraries you care. > > Boxes are a temporary crutch; if we decide to go with them, we have to be > honest > — it’s boxes forever, until the end of time. The V? story is a more stable > long-term story. (But if you have a better one, we’re listening.). > >> Here we want to introduce boxes not because value type are not objects but >> because value types are not nullable objects but T is a nullable object. > > You’re assuming the utility of V? after reification is zero, but that’s not > the > case. For example, suppose ArrayList is reified. Then the user gets the > choice > of erasure or reification by selecting ArrayList<V?> or ArrayList<V>. Erasure > has a bad rap, but sometimes it is desirable. V? as box allow that too. As i said there are two use cases for V?, not yet reified generics is one, backward compat is the other. Both semantics of V? give you backward compat, but do we we agree that this is a corner case. That why i don't want V? to be too powerful, because once generics are reified, the only use case that stay is backward compatibility, and for that the box semantics is enough. > >> So it's a different kind of box, for a different reason but that it should >> work >> like a box because our users are already familiar with the box model. > > I think we have to stop using the word box, because it seems very difficult to > have a conversation when we’re not agreeing on what “box” means. yes and no. Part of the appeal of the proposal is that if we cripple N? so remove the subtyping relation and this is debatable, i think also the capability to call fields/methods on it, the semantics is the same a classical box from the type system POV, you have auto-boxing, overloaded methods are resolved in a second pass (preferring V to V?), etc. So it's not a box by its runtime capability, it's a nullable value type at runtime, but by how it interacts with the Java type system. Let's call it a coffer if you prefer, i.e. it's like a box but for our precious value type. Rémi
