where are all the objects?

[Dan Heidinga]

I found today's discussion of giraffes and leashes that hold onto giraffes
really useful.  Sometimes we have the (flat papery) giraffe in hand,
sometimes we have the leash.  Whether we're directly holding it or holding
the leash doesn't change the giraffe.

Which fits with the VAO model.  Object references are clearly our giraffe
leashes but that doesn't give us a good word for the flattened
papery giraffe itself.  The challenge here is we're not describing a
property of the thing, we're describing the lack of something (the leash or
reference).  Add to this the VM doesn't provide guarantees about the
storage for the non-reference case - it's all VM discretion on whether to
flatten or not - so accurate terms feel like weasel words.

Does the VAO model feel less forced if we're explicit about references
being the difference?
 - A value object can also be represented without an object reference, as
primitives are today   // (*)

--Dan

(And I don't think I've ever typed "giraffe" this many times before)

On Wed, Aug 10, 2022 at 2:30 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220810/966e5990/attachment.htm>