This is the normal behavior. You are mutating the method's literal, which
becomes different. The instance is per method, so even if you do:
foo
#[1 2 3] at: 2 put: 50.
^ #[1 2 3]
You get #[1 50 3], which is easy to understand in this example, but can be
very tricky to understand in some cases.
I've introduced recently "read-only" objects (Object>>#isReadOnlyObject and
co). I am waiting for the VM repo merge which should happen in the next few
weeks to have this feature in the default Pharo VM, then I will be able to
compile method literals "read-only" by default. With this feature, the
#at:put: store will fail telling you that you cannot store into a read-only
object, which will solve the common problem, when one does not mutate a
literal on purpose.
Now as in Pharo everything is reflective, it will always be possible to
mark back the literal as "writable", mutate it, and still have this
behavior.
Best,
Clement
On Sat, Jul 9, 2016 at 10:22 PM, Peter Uhnák <i.uh...@gmail.com> wrote:
> Is this normal behavior?
>
> cls := Object subclass: #Something.
>
> cls compile: 'array
> ^ #[1 2 3 4]'.
>
> cls new array. "#[1 2 3 4]"
>
> cls new array at: 1 put: 55.
>
> cls new array. "#[55 2 3 4]"
>
> (cls>>#array) sourceCode "'array
> ^ #[1 2 3 4]'"
>
>
> So I can permanently change the compiled byte array in the method, which
> is weird.
>
> Shouldn't the behavior be either
>
> a) don't change the original byte array
>
> or
>
> b) change the source code
>
> Thanks,
> Peter
>
