Queries regarding value classes

[Julian Waters]

Hi Quân Anh, thanks for the reply,

I think I understand what you mean; Since value objects have no identity,
changing their fields would essentially mean the object is now entirely
different. However since that's the case, I'm still a little confused by
the semantics of what they really are. Specifically, most of their benefits
are centered around them being nothing more than their fields in memory,
but at the same time documentation states that they're referred to by
reference, which I find a little contradictory. If it's the former, they'd
be no different from primitives, and if the latter, they'd be the exact
same as identity objects, which has left me puzzled for quite some time.

Sorry for all the trouble, have a great day

best regards,
Julian

On Sun, Mar 13, 2022 at 4:26 PM Quân Anh Mai <anhmdq at gmail.com> wrote:

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