[squeak-dev] read-only literals

Paul DeBruicker pdebruic at gmail.com
Mon Mar 26 01:53:38 UTC 2018

Hi All,

I agree with David and think it should raise an error.  

If you make it a setting you'll be dealing with the consequences of
misuse/misunderstanding in perpetuity.  You could instead make the error
message that point to a wiki page (or help page) that lists all the ways to
fix the 'modifying a literal' error and why its useful and also some RB
transformation rules there a person could run against their package/image to
preemptively fix them.  

When there aren't active maintainers for packages there could be a section
on the wiki describing how to get a squeaksource admin to upload a user
created fixed package.  Then unused unmaintained packages aren't holding you
back and used ones get fixed.

Hope this helps


David T. Lewis 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.
> 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.
> 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).
> 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

Sent from: http://forum.world.st/Squeak-Dev-f45488.html

More information about the Squeak-dev mailing list