🇳🇱
Ya know the more I reflect on the languages I know the more I realize that outside of functional languages none of them really handle immutability well.
Consider that you want most of your objects to be immutable most of the time. Thats all well and good till you realize you want to be able to edit the objects in such a way that it creates duplicates that have some data changed but are likewise immutable.
This tends to stop working, almost entierly, once you get into subclassing. If you parent class has a method that returns a copy of itself with some data modified, this will break in children classes, since you want children classes to return instances of itself, not its parent.
Its not that you cant fix that, but the code gets very ugly very quickly. Generally you are forced to let the code handling the classes do the copying and editing itself, but that is pretty ugly too.
I have had this pattern problem in almost every OO language i messed with, Java, Ruby, Python, etc.
@freemo Assembly for protecting the memory should work. It might be easier to just use Assembly nested in the code or call cookie cutter code to do the same thing.
A read of the object into protected memory would allow two objects to exist at once. The secure processor would have the immutable one and the user mode would have the mutable one. Depending on what is needed, either could be called by reference.
There's the secure processing on modern CPUs. That's going to be some awkward Assembly but the object would be as immutable as possible while remaining mutable. It could also be done by using the OS.
@AmpBenzScientist Its not the physical mechanisms that enable immutability that is the problem, there are tons of good approaches there. The issue is more around the elegance of the whole process (namely mutate-and-copy paradigms)
