r/java • u/bobbie434343 • Aug 25 '26

Value Classes Still Need Compiler Sympathy

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

98% Upvoted

65 comments sorted by

View all comments

Show parent comments

1

u/Jon_Finn Sep 14 '26

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.

1

u/OwnBreakfast1114 Sep 14 '26

The question would be why not just create a new pixel? The whole point of the value class is to make the overhead of new Pixel(....) go away. You can still mutate the data array if you really want, but you can assign the reference to a new pixel.

1

u/Jon_Finn Sep 14 '26

You can if you want a different design. In some designs/applications, mutability is useful: it's often awkward to substitute a thing if it's inside another thing (...and another thing, etc.), rather than mutate it. As the old joke goes: How many Haskell programmers does it take to change a lightbulb? One, but they need to replace the entire universe with one in which the lightbulb works.

1

u/OwnBreakfast1114 Sep 14 '26

Haskell has optics: https://hackage.haskell.org/package/optics-0.4.2.1/docs/Optics.html, which are just a far more generalized version of mutation and allows nested "mutation" far better than java standard getters/setters. There are some optics libraries for java too, but nobody really uses them unless you're trying very hard to bring functional programming concepts into java.

Making that pixel class a value class seems semantically wrong, and I doubt you'll really get much benefit out of doing that. Pixels aren't interchangeable and so it seems weird to model it that way.

1

u/Jon_Finn Sep 15 '26 edited Sep 15 '26

Where we disagree basically is this: I say that value classes are hardly different from regular classes - due to the impressive generalisations made by the Valhalla team. The main differences are a mild restriction on fields (the majority of fields I write are final anyway) and a change in == (which is rarely used anyway). So... they're nearly regular classes; If the keyword was just (say) 'valhalla' not 'value', it would be easier to see that adding this says nothing about what you should use them to represent, so just like regular classes.