And now to your other thread:
On 8/10/2022 1:38 PM, Kevin Bourrillion wrote:
The VANO model does a lot of "doubling down" on the distinctions
between objects and values, which does have a certain "stuck in the
past" feeling to it. A benefit is "concreteness" and a feeling that
"there is plenty of solid ground under your feet that Valhalla is not
pulling out from under you". That feeling is important to me,
particularly because developers in the real world will regularly find
themselves going back and forth between pre-valhalla and post-valhalla
code for a very long time. A hazard is that it equips developers to
care more about that distinction that they really should *moving
forward*, particularly since the VM is a cheating cheater. Essentially
we're saying "for understanding, you can lean on what you know about
int-vs-Integer, but now understand why the distinction will matter
less and less to you."
(John associates VANO with "boxes and arrows". I think that's right
and good? It seems called for because an /arrow/ is the thing that
could be null instead.)
The VAO model does seem more forward-thinking. Why should we invest in
the question of when exactly objects "exist" or not when those objects
can't be programmatically distinguished from each other anyway, nor
from their corresponding values?
The eventual "final" presentation of value classes to users (in the
permanent documentation and the definitive seminal slide
presentations, and to *some* degree in the JLS itself) should anchor
on one model or the other. But these docs/presentations might also
want to say "and here's why you get to think of it this other way when
you want to". That may sound like trying to have it both ways, but...
I want to believe that as long as one is subjugated to the other it
would be fine. "Here's how little is *really* changing; here's how
your day-to-day modell gets to evolve because of that".
The VAO model says:
- classes have instances, which are objects
- An object _reference_ can refer to any object, identity or value
- A value object can also be represented directly, as primitives are
today // (*)
- We've unified under "everything is an object", but added: not all
objects require references
The uncomfortable part of this model is that while we are familiar with
the notion marked (*), because of primitives, we don't really have a
good name for it. So part of this is that there much bumbling and
fumfering around phrases like "represented directly" and "bare" and
other made-up words that we have to say "but but it's just like what you
know about primitives."
The VANO model says:
- classes have instances, but not all instances are objects. some are
values instead
- Each value class V gets a special box class V.ref, which has a
single field of type V.val, like the boxes we know
- The boxing and unboxing conversions, though, are super fast! Because
they're not burdened by identity preservation
- We've unified under "everything is a class instance" and kept "all
objects require references", and the spirit (but not performance) of boxes
My intuition is that if we can come up with a better term for
"represented directly" that doesn't feel forced, the things we dislike
about VAO will be lessened and its unification under "everything is an
object" will win the day.
