3 ms·
Nice little introductory essay on the concept. One wrinkle I've often pondered -- once you get copy by value semantics, do you really need immutability? I mea
by Pxtl 4y ago
Nice little introductory essay on the concept. One wrinkle I've often pondered -- once you get copy by value semantics, do you really need immutability? I mean immutability is more pure but it's also often a nuisance implement if an object has a lot of members and you need to do a lot of "copy but change this one member" operations.
- sparkie 4y agoOCaml has a nice solution: Functional Objects[1]. Instead of a member mutating something in an object, it just returns a copy of the object with the relevant changes. [1]:https://v2.ocaml.org/manual/objectexamples.html#s%3Afunctional-objects https://v2.ocaml.org/manual/objectexamples.html#s%3Afunction...
- int_19h 4y agoIt's a double-edged sword - by having your data immutable, you can also avoid copies. Or, better yet, the compiler can avoid them for you.
- mrkeen 4y agoI use Haskell, where the syntax to "copy but change one member" is: let newObj = oldObj { member = newMember } In Java, you use the builder pattern, which is not built in. So you use Lombok to generate it for you, and then you get in a fight with your team lead about not using Lombok because he heard about this-one-guy-who-had-a-problem-with-it-just-do-your-own-research-I-can't-be-bothered-explaining-it-to-you, so then you roll (and maintain) your own Builder object for every value class.