I've been thinking about immutability in Squeak too! And hell yeah
it's bigger than databases.

 - makes concurrency painless
 - improves testability
 - allows certain compiler optimizations that aren't possible when
there's mutable state
 - makes certain things formally provable that aren't when there's mutable state

I think these are all great reasons to experiment with. I'd like to
assert though: immutability should be introduced in a way that's
optional, and doesn't introduce any new syntax.

I'd like to ask an object #isMutable and be able to do certain things
differently if it answers false. Mutable objects are ones that have
state that can change.

Randal: FWIW, I think the Newspeak guys are playing with this stuff.

On Wednesday, March 17, 2010, Stephen Pair <stephen at pairhome.net> wrote:
> On Wed, Mar 17, 2010 at 12:27 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 17.03.2010, at 17:12, Chris Cunnington wrote:
>> Databases are for peasants. We are unique and occupy a unique position. Let's embrace that. Stop trying to turn us into shadows of Gemstone, Cimcom, or other merchants of tedium. If Kent Beck isn't happy with Squeak, I don't see it as our job to cater.
>>
>> There is nothing else on earth like us and what we do.
>> Squeak is a never ending game of capture the flag.
>>
>> Chris
>
>
> And even if it *was* only for databases it wouldn't hurt to support it in Squeak. It takes nothing away from the fun.
>
> And it's not only about databases.  I would be interested in immutability implementations that go beyond what VW does.  I would like to see some thought given to deep immutability and irrevocable immutability (irrevocable at least at some language layer).  These facilities would be immensely useful for safely and efficiently sharing and replicating state between processes.
>
> - Stephen
>
>

-- 
Casey Ransberger