Smalltalk › Squeak › Squeak - Dev

Re: [Pharo-dev] Array literal changes of a compiled method

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Eliot Miranda-2

Re: [Pharo-dev] Array literal changes of a compiled method

Hi Juraj,

On Mon, Sep 14, 2015 at 4:56 PM, Juraj Kubelka <[hidden email]> wrote:

Hi,

I have a test case like that:
-=-=-
testIncrementBy
prefix := MyObject new numbers: #(1 10); yourself.
prefix incrementBy: 10.
self assert: prefix numbers equals: #(1 20).
-=-=-

and the byte code starts like that:
-=-=-
57 <40> pushLit: MyObject
58 <CC> send: new
59 <88> dup
60 <21> pushConstant: #(1 10)
-=-=-

If I run the test case, it is green, but the byte code changes into:
-=-=-
57 <40> pushLit: MyObject
58 <CC> send: new
59 <88> dup
60 <21> pushConstant: #(1 20)
-=-=-

The #incrementBy: method looks like:
-=-=-
incrementBy: aNumber
numbers at: 2 put: (numbers at: 2) + aNumber
-=-=-

Is it correct that it also changes the method byte code?

No, ut this does happen. hat I suspect you're seeing is the fact that in the Pharo and Squeak implementations, literals are not immutable. So if you were to assign to a literal Array in a method's literals that assignment would not cause an error, and worse, would not be visible because the mehtods source code would be unchanged.

We shall have a proper fix for this in a future release where we will support fully immutable literals. For now the correct respponse shoudl be to find out where in your code the literal is assigned to and to not do that. Of course adding a copy is also fine.

I can put "#(1 10) copy” into the test case.
I am just curious if it is a feature or bug.

It's a bug, but an ancient one. Some Smalltalks, such as VisualAge and VisualWorks have fixed this by introducing support for immutable objects, but the {haro/Squeak Vms have yet to provide this. I expect to implement it in Spur some time next year.

Tested in Pharo4.0, Latest update: #40613.

Cheers,
Juraj

_,,,^..^,,,_

best, Eliot