[squeak-dev] read-only literals
Bert Freudenberg
bert at freudenbergs.de
Mon Mar 26 12:16:04 UTC 2018
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>
More information about the Squeak-dev
mailing list
|