Hi David,

On Sun, Mar 25, 2018 at 6:21 PM, David T. Lewis <lewis at mail.msen.com> wrote:

> Hi Eliot,
>
> I have not given this much thought, but just to get the discussion going
> I'll answer from the POV of maintaining a package like OSProcess. As the
> maintainer, I would be happier to just fix my code and be done with it,
> as opposed to trying to answer questions from various people who might
> or might not have have yet another obscure preference set.
>

Good :-)


> But the counter argument is that not all of the useful external packages
> have active maintainers, and we don't want to set up a situation where
> those packages cannot be used. I don't know if that would be the case
> here, but if so we would be well advised to provide a preference to keep
> those packages useable.
>

But since it's trivial to fix these issues I'm not worried by this.


>
> If we do add a preference, then I would rather that the default be to
> simply raise an error (your preferred state of affairs), and the preference
> would exist only in the interest of allowing existing (unmaintained?)
> packages to be loaded and run.
>
> 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).

Dave
>
>
> On Sun, Mar 25, 2018 at 04:18:32PM -0700, Eliot Miranda wrote:
> > Hi All,
> >
> >     the VM now has support for read only objects, and the first logical
> > application is for literals, making boxed floats, strings, symbols,
> arrays
> > and byte arrays read-only.  Doing so is trivial; only two methods need to
> > be modified (see attached).  AFAIA little or no core code is broken by
> > making literals read-only.  However, when I ran the test suite with
> > read-only literals in place, several tests were broken.  These are things
> > like creating null-terminated strings for testing OSProcess, by replacing
> > spaces in string literals with zeros, etc.
> >
> > When we added read-only literals to VisualWorks in something like vw7.0
> the
> > balance of opinion was that we should not break user code.  Hence we
> > implemented a preference scheme with three states:
> >
> > - By default, an attempt to modify a read-only literal would silently
> make
> > the literal mutable temporarily,update it and then reenable
> read-onlyness.
> > - A second state would issue a warning to the transcript, while doing
> what
> > the default did.
> > - The third state would raise an error
> >
> > Remember that all one needs to do to fix code that modifies literals is
> to
> > send copy to the literal before modifying the copy, since copies of
> > read-only literals are mutable.
> >
> > I was on the side of only raising an error, but was overruled :-).  I
> > wonder what this community thinks.  If there are strong views that user
> > code should continue to function unchanged (even though it is modifying
> > literals, which is so so wrong :-) ) I'm happy to implement a scheme
> > similar to that for VisualWorks.  But I'd rather not have to and simply
> > have people fix their code within a system that raises an error whenever
> an
> > attempt is made to modify a literal, and is as simple as possible, but no
> > simpler ;-)  Thoughts, opinions?
> >
> >
> > _,,,^..^,,,_
> > best, Eliot
>
>
> >
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180325/0278eacc/attachment.html>