Queries regarding value classes

[Julian Waters]

Hi all,

I'd like to discuss several topics related to the current draft on value
classes.

As mentioned in another post to this list at
https://mail.openjdk.java.net/pipermail/valhalla-dev/2022-January/009871.html,
currently value classes are specified as immutable, with all fields being
declared as final. If I understand this correctly, value based classes,
unlike the true primitives which work is currently focused on, can still be
referred to by references; It is only identity that has been given up. In
that instance, naively speaking, wouldn't it be possible for value objects
to have mutable fields? In the same way that one can reference the fields,
one might possibly be able to also change their values through the
available object reference as well. From what I can tell, value objects are
planned to work internally by decomposing them to nothing more than their
constituent fields and reconstructing them elsewhere. If that is the case,
shouldn't modification of their fields be possible? To me it seems the
modification would simply modify the copied value object *b *while leaving
original value object *a *unchanged, which sits perfectly with the
constraint that identity should not be supported. Am I mistaken in my
assumption?

Additionally, if the above holds true, I also suggest allowing an object to
be declared as value based at the site of their usage, instead of just at
their definition. Something like

// Item is by default an identity class, but the field "item" here is now
// a value object due to the declaration of value
value Item item = new Item();

would allow typical identity classes to be treated as value objects where
they're used. This would, to me, present a great deal of flexibility as one
could then choose how to allocate a particular object without
constraining *every
*instance of that class to a specific value/identity dichotomy, and also
avoids the hassle of having to know which classes should be value or
identity types ahead of time. On a side note, the current proposal also
includes the ability to mark records as value based, given that records are
meant exclusively as data classes, I suggest we flip that around and
instead have records as *value based by default, *and instead allow marking
them as identity objects explicitly if required, with the currently used
ref keyword (Or whatever ref will eventually become), both at definition
and when an actual instance is constructed, as mentioned above. This could
save frustration from having to type value over and over whenever writing
the definition of a new record.

Have a great day, hope I can hear your opinions on this! :)

best regards,
Julian