3 ms·
This sounds eerily similar to persistent data structures (eg in FP contexts like Clojure): updated values share as much[1] as possible with their inputs, and cr
by eyelidlessness 4y ago
This sounds eerily similar to persistent data structures (eg in FP contexts like Clojure): updated values share as much[1] as possible with their inputs, and create new values only[1] when they differ. Granted in FP contexts, this is primarily an optimization, transparent[2] to the programmer actually using those values in a program.
From the perspective of such a programmer, I can’t think of a scenario where I’d want both value and reference equality semantics for the same objects. Is it reasonable to assume that the “smartness” here is likewise focused on making immutability perform well, rather than on use cases where value and reference equality are simultaneous considerations?
1: Handwaves away implementation details. General cautions about abstractions leaking apply.
2: Exceptions may apply[1].
- ImprobableTruth 4y agoYeah, it's also originally from the FP side. There it started I believe because people were looking how to easily make immutable updates to deep structures, since the normal way is pretty boilerplate heavy in comparison to the mutation way of just chaining accessors for an update. And you're close, it's about using immutability to make value equality cheap by making reference equality a proxy for it. If you don't use mutations, value equality implies reference equality and is thus equivalent (since reference equality already normally implies value equality). That means you can get away with just a single pointer comparison in comparison to completely traversing both structures. This is e.g. what React does to determine whether arguments of a component have changed. (Well, at least I also struggle to think of a scenario where both types of equality are semantically important).