Allright. But the problem happens for any literal you mutate, not only byte
arrays.
For example this one:
foo
#(true nil 10) at: 2 put: 50.
^ #(true nil 10)
Answers... #(true 50 10)
The most common problems are with Array, not ByteArray.
Even worse, it can happen with LargeIntegers, Floats, ScaledDecimal, etc.
Hopefully read-only objects will solve most of the problems.
On Sun, Jul 10, 2016 at 10:51 AM, Peter Uhnák <[email protected]> wrote:
> Thanks for the explanation!
>
> I've this byte array syntax for the first time and I don't think that I
> will be making heavy use of it, so it shouldn't be a too big problem —
> since now I understand the behavior, so I can keep it in mind.
>
> Thanks,
> Peter
>
> On Sun, Jul 10, 2016 at 7:43 AM, Clément Bera <[email protected]>
> wrote:
>
>> 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 <[email protected]> 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
>>>
>>
>>
>
