Queries regarding value classes

[Stig Rohde Døssing]

Hi Julian,

Sorry if I'm misinterpreting, but I get the impression that what you're
asking for isn't really mutable value objects, but a nicer syntax to get a
copy of "x" where "a" is set to 3, right?

One of the Amber docs describes an idea for "with expressions", which might
be relevant here.

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md#with-expressions-in-java

Den tor. 17. mar. 2022 kl. 03.01 skrev Julian Waters <
tanksherman27 at gmail.com>:

> Alternatively, something like
>
> X x = new X(1);
> x.a = 3;
>
> could be valid while
>
> final X x = new X(1);
> x.a = 3;
>
> would not?
>
> best regards,
> Julian
>
> On Tue, Mar 15, 2022 at 11:12 AM Julian Waters <tanksherman27 at gmail.com>
> wrote:
>
> > So if I understand correctly, value objects are essentially the same as
> > JEP-401's primitives but with nullability, and according to JEP-401,
> > guarantee of atomic modification?
> >
> > "you are saying "change the a field of the object referred to by x to
> 3.""
> >
> > Regarding this earlier x.a = 3 example, if X was a good ol' identity
> > object, x would then be a reference to the actual instance, and we'd
> simply
> > follow the reference to where the actual object is stored and set a to 3.
> > But if it was a value object, my understanding from your previous post is
> > that it would be stored directly on the abstract (Ignoring HotSpot's
> actual
> > complex implementation) stack to be operated on as a bunch of fields with
> > no additional metadata other than the check for null. What's stopping us
> > from then changing those fields directly? Like Quân Anh mentioned
> earlier,
> > we would've effectively created a new object if we did do that, since a
> > value object has no identity, but wouldn't we have technically changed
> the
> > value of a after initialization? At the very least, I'd say it would be
> > useful syntactic sugar to be able to do x.a on a value object instead of
> > having to do new X(3); every time we wanted to change it, unless a is
> > explicitly marked as final, without affecting == or related checks in any
> > way, since (from what I know) value objects are compared by field with
> ==.
> >
> > Apologies for my lack of knowledge in this area, it still feels like I
> > haven't really gotten a correct idea of what value types really are,
> > especially compared to the true primitives of 401
> >
> > Thanks for the reply and have a great day!
> >
> > best regards,
> > Julian
> >
> > On Tue, Mar 15, 2022 at 5:59 AM Brian Goetz <brian.goetz at oracle.com>
> > wrote:
> >
> >> You are (understandably) conflating the properties of identity with the
> >> properties of reference-ness.
> >>
> >> If you say
> >>
> >>     x.a = 3
> >>
> >> you are saying "change the a field of the object referred to by x to 3."
> >> The key to this sentence is *the object*; in order for assignment to
> make
> >> sense, you have to know exactly which variable you are talking about.
> And
> >> if that variable is an instance field, then you have to know exactly
> which
> >> object it lives in.  This is where identity comes in; if x is a
> reference
> >> to an identity object, we then know how to find it.  Which means, you
> need
> >> an identity in order to be able to talk about mutability in a
> well-defined
> >> way.
> >>
> >> So if that's true, what is a *reference* to a value?  This is the
> >> confusing part.  If you think in terms of implementation, you'll
> probably
> >> think "reference means pointer", which puts you into a C frame of mind,
> >> because pointers always point at things.  But that's not what reference
> >> means in Java; its a more abstract kind of indirection.
> >>
> >> The distinction between int and Integer may be helpful.  At one level,
> >> int and Integer may seem like "almost the same sets of values"; the
> Integer
> >> value set has one more value -- null -- than the int value set, and for
> >> each of the other values, there is a bidirectional, 1:1 mapping between
> the
> >> two value sets.  But if we look closer, in fact these value sets are
> >> disjoint!  An int is not an Integer (even if they describe the same
> >> number.)
> >>
> >> So one big difference between references and values is nullability; null
> >> is a special kind of reference, the reference to no object at all.
> >> Reference types can be null; primitive types cannot.  (There's another,
> >> even more subtle distinction, which is tearability, which comes from the
> >> guarantees of the Java memory model.)
> >>
> >> If we have a value class:
> >>
> >>     value class X { }
> >>
> >> this gives rise to a reference type X, whose values are references to
> >> instances of X.  But those instances do not have identity, which means
> we
> >> can freely shred an X into the values of its fields, and later
> reconstitute
> >> it into a new X, all without anyone noticing.  That's what the lack of
> >> identity enables.  But the flip side of that means that any given X does
> >> not "live" anywhere; it is just a loose aggregation field values, which
> >> behaves like an object when called upon to do object-y things.
> >>
> >>
> >>
> >>
> >>
> >> On 3/13/2022 5:46 AM, Julian Waters wrote:
> >>
> >> 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> <
> 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> <
> 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
> >>
> >>
> >>
> >>
>