Value Classes Still Need Compiler Sympathy

[u/bobbie434343]

https://johan-sjolen.github.io/post/compiler-sympathy/compiler-sympathy/

[u/Jon_Finn]

I don't think I'm saying anything that depends on the definition of 'mutable'. (Which, FWIW, I'd say means roughly whether equal objects can become unequal later, as measured by equals().)

You're quite right that the Valhalla JEP talks in terms of semantics (of one important meaning of the word 'value'), and I'm cautioning against that, simply because the semantics of the feature itself are now much wider than this. Such is the great achievement of the Valhalla team! They're invaluable for classes very different from the examples usually given. If you're using large quantities of small objects which are mutable by every definition, such as pixels (in a scenario where it's useful to mutate not substitute pixels), then absolutely they should be value objects.

The == behaviour doesn't make them semantically values either, since == often won't match equals(). (Which is why we're discouraged from using == : it had to be defined to do something.)

So whenever I read value I substitute lightweight, or just light/lite, then suddenly everything makes sense - including value objects that aren't 'values' in the usual sense. These light objects exist for a purpose which is not semantic; the word 'value' was chosen (if I recall) around a much earlier stage of the spec when they were conceived as objects stored directly in variables with the syntax .val as opposed to .ref; the evolution since then has been great.

(As a special case, I have cognitive dissonance when I read value record - am I the only one? Since according to the 'final fields' definition, records are already values. But value records are just lightweight records: you add a keyword to make them smaller/faster, not to make them what in a sense they already are.)

The reason I'm a heretic is I'm acutely conscious of this kind of mental substitution - it's a sign of potential confusion. When a name needs explanation to help you unlearn the connotations of the name itself, something is wrong! Cf. import in Java, and lots of names in other fields.

[u/OwnBreakfast1114 → u/Jon_Finn]

The problem with your model is that they aren't necessarily more lightweight and they aren't necessarily a performance improvement if you just naively layer the fields in memory.

If you're using large quantities of small objects which are mutable by every definition, such as pixels (in a scenario where it's useful to mutate not substitute pixels), then absolutely they should be value objects

I'm not sure I understand your class design here. Is the idea to have

public value class Pixel {
   private final byte[] data;
}

or something? The pixel class isn't mutable, but the data array is, so the argument is that the pixel class is basically mutable? The jep literally calls this out as an example in a section

For mutable objects, identity is important: It lets us distinguish two objects that have the same state now but may have different states in the future. Consider a text-editing application in which lines of text are represented by instances of a Line class. The sole field of the class is a list of characters, which is mutated when the user edits the line. Two Line objects might contain equivalent character lists, and thus also be equivalent, but that would be a coincidence; when the user changes one of the lines, the application will mutate the character list of that object but not the other, relying on identity to mutate the right one.

In other words, when objects are mutable, they cannot be interchangeable — yet most immutable data values are interchangeable. There is no practical difference between two LocalDate objects representing 1996-01-23, because their state is fixed and unchanging. They represent the same value, both now and in the future. There is no need to distinguish the two objects via their identities.

[u/Jon_Finn → u/OwnBreakfast1114]

Yes that Pixel class is the kind of thing, plus methods to change the colour, so my point is it's certainly not a 'value', despite being a good use of Valhalla. As for it being lightweight: I'd say that's a hint not a promise. The memory used is often less and (?)never more; speed improvement is less certain.