[Vm-dev] Re: [Pharo-dev] Should literals be immutable ?

[Levente Uzonyi]

On Mon, 27 Oct 2014, stepharo wrote:

> Levente
>
> I think that the first step is not to make sure that you cannot hack inside literals like mad. But to make sure that in 99.99 % of the case, this assumption can hold.
>
> Stef

Let me sum it up:
- The question is (by Clement) if it's okay to not implement the slow path.
- He assumes that he doesn't have to implement it if literals are immutable.
- I showed that literal immutability is not enough to avoid impelemting 
the slow path.

So immutability doesn't affect anything about the need for implementing of 
the slow path. If Clement decides to not implement it, then one will be 
able to get the system into an inconsistent state, no matter if literals 
are immutable or not.

If you think that the inconsistent state can only be achieved by hacking, 
then here's another example without "hacks":

SomeClass >> #someMethod

 	^someBoolean
 		ifTrue: [ Array with: 1 with: 2 with: 3 ]
 		ifFalse: [ Array empty "we don't have to create a new array for this, right? :)" ]

SomeOtherClass >> #someOtherMethod: anArray

 	| copy |
 	anArray doSomething.
 	"let's grow that array"
 	copy := Array new: anArray size.
 	copy replaceFrom: 1 to: anArray size with: anArray startingAt: 1.
 	anArray becomeForward: copy. "this is really cheap in Spur (and in VW; even collections and streams use it)"

ThirdClass >> #yetAnotherMethod: aSomeClass

 	| x |
 	x := aSomeClass someMethod.
 	y someOtherMethod: x.
 	^x

And now, when #yetAnotherMethod: is sent, we swap the literal in Array 
class >> #empty with another non-empty array. Based on Eliot's comment 
about VW, I'm pretty sure the VW guys had problems like this, despite of 
having immutable literals.

Levente