Queries regarding value classes

[Quân Anh Mai]

Hi,

Regarding your concern of mutable value objects, having a mutable
identity-less object is illogical. Because a value class does not have a
unique identity, upon modification, the object is changed to become another
object. A value object is immutable in the same way that an int is
immutable. You can change a variable int a from containing a value of 3 to
a value of 4, but you can’t change the number itself, it has been
mathematically and programmatically defined to be a specific bit sequence.
Similarly, you can change a variable Point a from enclosing the point (3, 4)
into the point (2, 5), but you can’t change the coordination of the points
themselves, they have been (in this case) also mathematically defined. Your
understanding of how value classes work is also not correct. The fact that
a value object can be deconstructed to its fields does not mean that it
will. This is simply an optimisation choice of the compiler.

Regards,
Quan Anh

On Sun, 13 Mar 2022 at 15:42, Julian Waters <tanksherman27 at gmail.com> wrote:

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