I do think the term immutability is being thrown around a bit here somewhat in denial of the reality that what we are in the very process of doing is mutating the instance. Is immutability even the goal? I mean, yes the wbtree is persistent in the sense that older versions of an object are never overwritten, but that doesn't preclude us from representing changes to an object in subsequent updates to the tree and expressing its value at a given point in time as MVCC. Any given version of the object is immutable, but the object itself can model mutability without detracting from that.
Exactly what I was going to write about next!
When we create a persistent object, we assign it a unique object id. We cannot change the object, but we can change mapping from ids to objects. The procedure remake-instance does this. remake-instance takes an persistent object and some initargs and creates a brand new object, but it updates the object-map with the old object id. We simulate slot mutation by creating a new object that differs only in that slot value and giving it the old object id.
This simplifies transaction handling quite a bit. If a transaction aborts we want to restore the world to the state it was in when we started. Since we didn't actually change the original object, all we need to do is go back to using the old object map.
The question, to my mind, is when you're thinking about immutability as a philosophical thing (where you use it to prove that certain operations are safe/unsafe, that certain properties will persist, blah blah) that contrains your design and coding, and when you're thinking about it as just an implementation technique that you can ignore (at some potential cost in efficiency) at the levels that you care about.
ReplyDeleteFor instance, physical atoms are (mostly) immutable under the conditions we live in. But when we make or destroy stuff by machining, welding, cooking, eating etc we can (mostly) ignore that fact and go about our business.