<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><span style="font-family:arial,sans-serif;color:rgb(34,34,34)">On 26 March 2018 at 01:18, Eliot Miranda </span><span dir="ltr" style="font-family:arial,sans-serif;color:rgb(34,34,34)"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span><span style="font-family:arial,sans-serif;color:rgb(34,34,34)"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi All,<div><br></div><div>    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.</div><div><br></div><div>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:</div><div><br></div><div>- By default, an attempt to modify a read-only literal would silently make the literal mutable temporarily,update it and then reenable read-onlyness.</div><div>- A second state would issue a warning to the transcript, while doing what the default did.</div><div>- The third state would raise an error</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div><br><div class="m_-4655848801712847861gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">​+1 for read-only literals in general.​</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Trying to modify a literal should raise a Deprecation Warning for at least one release cycle, with an option to silence it.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">In some future release we can make it an error.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- Bert -</div><br></div></div></div></div>