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