Objects vs. values, the continuation

[Kevin Bourrillion]

On Sun, Apr 24, 2022 at 11:58 AM Brian Goetz <brian.goetz at oracle.com> wrote:

I think what is missing from our presentation — and likely key to
> succeeding — is how to describe “compound value” in a way that feels like a
> thing.
>

Well, a `double` is already a compound value that feels like a thing. Java
just hides the internal structure instead of having us access d.exponent
directly etc. Is that a useful angle? I'm not sure, but right now I think
it is.



> Users mostly understand how primitives are different from objects, but
> “loose bag of primitives with limited integrity constraints” is a new and
> complex concept
>
that I worry users will have a hard time keeping separate from their
> conception of object.  Once we start aggregating fields, the temptation is
> to say “that’s like an object” and then carry with it some incorrect
> assumptions of integrity (e.g., final field guarantees)
>

Yes, no matter what there will be some list of mantras we have to try to
retrain people with. We want the list to be small, natural, learnable, but
we can't make it go away. So in what I propose, one of those mantras is

"my custom value types are like int, but composite(compound) --> an int was
never an object and it still isn't --> so neither are my value types"

(Of course, I'm still on the path that we *want* users to lean on their
existing understanding of int-vs.-Integer for understanding
MyType.val-vs.-MyType.ref, which I know has been controversial in the past.)

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com