[squeak-dev] read-only literals
David T. Lewis
lewis at mail.msen.com
Mon Mar 26 11:57:19 UTC 2018
On Sun, Mar 25, 2018 at 07:33:40PM -0700, Eliot Miranda wrote:
> Hi David,
>
> On Sun, Mar 25, 2018 at 6:21 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>
> >
> > Off topic for your question, but just for my own understanding - why is
> > it good for a ByteArray to be read-only? I would have thought that it
> > would be just an array of things that happen to be very small positive
> > integers (sorry I am sure this has been discussed before).
> >
>
> This example applies to strings, arrays and byte arrays:
>
> Object>>modifyLiteral
> | stream |
> stream := ReadWriteStream on: #[1 2 3 4] from: 1 to: 4.
> {stream contents. stream reset; nextPut: 255; setToEnd; contents}
>
> In the current system, the first time this is run it answers #(#[1 2 3 4]
> #[255 2 3 4]) and thereafter (or until it is recompiled) it answers #(#[255
> 2 3 4] #[255 2 3 4]). Ugh :-). With read-only literals it raises an
> error; the at:put: in nextPut: fails and raises ModificationForbidden.
> Note that such modification of literals is invisible unless one decompiles
> the method. The source of the method remains unchanged, cloaking the bug.
>
> Note that changing the example to
>
> Object>>modifyCopyOfLiteral
> | stream |
> stream := ReadWriteStream on: #[1 2 3 4] copy from: 1 to: 4.
> {stream contents. stream reset; nextPut: 255; setToEnd; contents}
>
> causes the method to behave unsurprisingly. Hence my claim that fixing
> these issues is trivial (deepCopy can be used to produce a mutable copy of
> a literal array of literals, for example).
>
Thanks, I understand now. I am fairly sure that I've been bitten by this
before, so I am happy to see it become less "surprising".
Dave
More information about the Squeak-dev
mailing list
|