On 30.03.2010, at 11:45, Bryce Kampjes wrote:
On Thu, 2010-03-18 at 16:40 +0100, Bert Freudenberg wrote:
On 18.03.2010, at 16:30, Ralph Johnson wrote:
On 3/18/10, Bert Freudenberg bert@freudenbergs.de wrote:
With true immutables you can start developing in a mixed object/functional style, which would allow interesting optimizations, e.g. for concurrency, memoization etc.
I've developed in a mixed object/functional style for years, and I think a lot of other people do, too. You don't need language support for this, though I expect it would be helpful. It makes concurrency and distributed programming easier, and is important when you are dealing with databases. Eric Evans calls this "Value Object" in his book "Domain Driven Design".
-Ralph Johnson
Right, the style is possible without VM support in your own subsystem. But being able to *guarantee* immutability would allow to generalize this beyond your own special-purpose code. And possibly it would enable further VM-level optimizations.
Even perfectly VM enforced immutability isn't enough to allow optimisation if you still allow become:. It's always possible to swap out the immutable object with a different one via become:.
It's fine to swap immutable objects, unless the object holding the reference is itself unmutable. No instance variable of an immutable object can be stored into, not even by become:. Obviously, become: would have to honor the immutability flag:. For references inside immutable objects, become: becomes a forward-become (or a no-op if both were immutable):
a := Array with: A new. b := Array with: B new beImmutable. c := (Array with: C new) beImmutable. a first become: b first. "a points to the immutable B instance, b to the A instance". a first become: c first. "both a and c now point to the immutable C instance"
- Bert -