[Vm-dev] Re: [Pharo-dev] Should literals be immutable ?
leves at elte.hu
Mon Oct 27 23:19:19 UTC 2014
On Mon, 27 Oct 2014, stepharo wrote:
> 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.
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
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 |
"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.
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.
More information about the Vm-dev