5 ms·
Creating a new value only gives you a stale data problem if you had pointers to the old value. You don't have to have pointers like that, it's a choice. To tak
by garethjrowlands 6y ago
Creating a new value only gives you a stale data problem if you had pointers to the old value. You don't have to have pointers like that, it's a choice.
To take an obvious example, you might load a value from a database (company or employees, say), create a new value (with the higher salary, say), then write the new value to the database.
- winstonewert 6y agoI think the point being made here was that alternative approach don't eliminate the difficulties of global state. Simply using immutable object doesn't make all your problems go away, it makes them different. I think it makes them better, but let's not pretend that all the challenges of dealing with state can be eliminated.
- garethjrowlands 6y agoQuite so. I was just trying to make some small suggestions on how to handle the consequences of making that object immutable. Here are some links along the same lines: * _Aggregate Roots_ in DDD limit pointers, https://martinfowler.com/bliki/DDD_Aggregate.html https://martinfowler.com/bliki/DDD_Aggregate.html * Guidance on where to mutate, _Functional core, imperative shell_, https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct... > using immutable object doesn't make all your problems go away, it makes them different Yes, and here is a concrete example of the kind of 'different' problems you get: nested immutable structures, say `a.b.c.d`, become harder to update than simply `a.b.c.d = newValue`. The functional solution for this is 'lenses' (and other 'optics'). My favourite Kotlin framework that I use in my day job provides lenses for HTTP - URL query parameters, request and response bodies and so on - which work very well.