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