More on your annotation proposal: One way to look at it is that you are proposing two new kinds of concrete classes to go with our old object class.
- object class = what we have today: identity-rich, nullable, not flattened - value class = new, flattened*, not nullable, identity-free - enforced value-based class = new, nullable, not flattened, identity-free (* VM folks say "flattenable") Your annotation almost succeeds in being pure translation strategy, except that the JVM needs to be told to take care of the array type. So it's a little more than "just an annotation for javac". Dan seems to want to migrate many classes (most not enumerated) as EVBCs. And certainly LocalDate and friends would seem to slide easily into this mold. If we can implement EVBCs easily as a one-off from full value type, in the context of L-world, should we try it? People responsible for user model (hi Brian!) might say "yuck, we are admitting design failure by giving a consolation prize to the VBCs, instead of the real VTs promised". Maybe EVBCs are the best engineering compromise, or maybe we just cut EVBCs off the feature list and say "VT or VT not", at which point people who wrote VBCs will have sad decisions to make, and Dan will tell them not to migrate at all. From a VM POV, I think EVBCs are simple to implement on top of L-world, and so seem worth the experiment. One challenge will be to resist feature creep on EVBCs that would entrench them in a position as a true third kind of class. To avoid that, I like the idea of making them a one-off of one of the prime types: objects or values. And given that choice, having an annotation tweak them from a value type seems like a fine choice, at least from the VM POV. — John On May 14, 2018, at 4:13 PM, Remi Forax <[email protected]> wrote: > > I think i prefer a declaration site annotation like @ValueBasedClass to a use > site annotation ValueRef<V>. > > For me a value based class, if you want to be as compatible as possible, is a > reference type (so 'L') that behave like a value type at runtime, so the JIT > can see it has a value type at runtime and can unbox it at will and > buffer/box it before calling a method at the horizon of the inlining blob. > > So as a library designer, i can choose to either replace a class by a real > value type and it will fail if null is present or as a value based class if i > value (sorry !) the backward compatibility more than the performance. > > Note that even if we solve the null issue when a reference type is changed to > a value type and i think it's not something we should focus on, there is > still the problem of the identity, so transforming a reference to a value > type will never be 100% compatible. > >
