[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