On 26 March 2018 at 01:18, Eliot Miranda <eliot.miranda at gmail.com> 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
>

​+1 for read-only literals in general.​

Trying to modify a literal should raise a Deprecation Warning for at least
one release cycle, with an option to silence it.

In some future release we can make it an error.

- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180326/8079e6f6/attachment.html>