where are all the objects?

[Kevin Bourrillion]

I thought we had a good discussion this morning. Some random followups:

I like the concept of identity as akin to an extra field that only identity
classes have, very much. It should feel like an "extra" feature, and purely
behavioral in nature. That means I like to untie identity from
addressability; push back on the idea that a reference encodes the object's
identity in any way. It's instead some opaque "location" and we have no
further expectations about it.

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".


On Tue, Jul 26, 2022 at 3:42 PM Dan Smith <daniel.smith at oracle.com> wrote:

> On Jul 22, 2022, at 9:04 AM, Kevin Bourrillion <kevinb at google.com> wrote:
>
> Note that *some* decisions which produce strong initial antipathy in the
> minds of users will actually become good teachable moments! "Here's why the
> reaction you had was tied to old assumptions that we are intentionally
> leaving behind for these good reasons." Even a user who doesn't *agree* with
> the decision can still hang their *learning* onto this. In fact I think
> some of the *best* teachable moments will be like that.
>
>
> This seems like a really good piece of wisdom to hold on to in all of our
> terminology/model discussions. Unintuitive != bad. Thanks!
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220810/d6f5eb9a/attachment-0001.htm>