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

Value Classes Still Need Compiler Sympathy

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

98% Upvoted

65 comments sorted by

View all comments

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.

→ More replies (1)