3 ms·
> DateDatum lastUpdate = now (); //... doSomething(); lastUpdate = now(); Yes, this highlights the crux of the argument: MutableDate lastUpdate = now(); doSom
by richhickey 17y ago
> DateDatum lastUpdate = now (); //... doSomething(); lastUpdate = now();
Yes, this highlights the crux of the argument:
MutableDate lastUpdate = now();
doSomething();
lastUpdate.changeInPlace();
versus:
ImmutableDate lastUpdate = now();
doSomething();
lastUpdate = changedVersionOf(lastUpdate);
In the first case, when someone reads lastUpdate they get a chunk of memory that could change right out from under them, with no clear recipe as to how to obtain a consistent value. In the second case, they get a consistent value they can use without worrying or synchronization. The first conflates identity and state, the second separates them.
Now, all is not right with the second case, as there still aren't coordination semantics for putting new values in lastUpdate:
TransactionalRef<ImmutableDate> lastUpdate = now();
or
AtomicRef<ImmutableDate> lastUpdate = now();
or something similar would fix that. It's not a matter of removing mutable memory, but one of using it in a way with clear coordination semantics, other than "good luck with that".