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

2014-10-28 0:19 GMT+01:00 Levente Uzonyi leves@elte.hu:

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

But is there a becomeForward: in VW?