[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

[Colin Putney]

Igor wrote:

> In theory, of course we can enforce anything, but in practice that
> means a lot of complex code with many checks at VM side.. This is not
> what i like to see in a first place, especially knowing that Squeak
> lived well so far without any immutability and it does not feels like
> we miss it badly.

Andreas responded:

> I absolutely do. There were several situations (for example in Croquet
> and at Teleplace) where we changed our designs to the worse merely due
> to the lack of immutability support. The main thing that immutability
> fixes is to prevent accidental modifications of objects thought to be
> immutable (method literals for example), which when they happen are
> *extremely* hard to find. But it also gives rise to many other
> interesting techniques (read-only transactions etc).

I have to agree with Andreas here. I've used immutability to good
effect in VisualWorks, and run into several situations where I wanted
it in Squeak and had to make do with a work around. Avi's WriteBarrier
package is one of those workarounds.

To be honest, I'm a little puzzled by the resistance to immutability.
It's not like this is a new idea with unclear semantics or unknown
utility. The VisualWorks implementation is simple and useful.
VisualWorks is still the fastest Smalltalk around, so the performance
impact can't be *too* high. VisualWorks is fairly similar to Squeak,
so it's not unreasonable to use it as a model for considering
immutability in Squeak.

Now, maybe there really are problems with the VW, VA or Gemstone
implementations, and if so, let's hear about them. "It's not
necessary" isn't a good argument, because nothing is really
necessary—assembly works fine. What are the costs, benefits and
trade-offs of VM-supported immutability?

Colin