[Vm-dev] Re: [Pharo-dev] Should literals be immutable ?
nicolas.cellier.aka.nice at gmail.com
Tue Oct 28 11:50:44 UTC 2014
2014-10-28 0:19 GMT+01:00 Levente Uzonyi <leves at elte.hu>:
> 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
> - 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 |
> 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.
> 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.
But is there a becomeForward: in VW?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev