[squeak-dev] enabling read-only literals...

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Mar 11 21:35:34 UTC 2020


Hi Eliot,
IMO you can proceed, it's better to introduce this kind of changes in early
stages of the release cycle.
Anyway, it's 6.0, not 5.x ;)

Once upon a time, I did purposely use mutable literal array as shared state
with a scope local to single method (that is without leaking the scope thru
a class var).
It's possible I also saw that trick once or twice, but its really an abuse
of undocumented and implementation defined behavior.
Anyway, we can decide to later add a defaultAction or better let that
responsibility to "clients" unwilling to change their code.

IMO, we should start gathering release notes about those important changes,
otherwise it's a lot of work that we postpone to the release team.

Le mer. 11 mars 2020 à 22:10, Eliot Miranda <eliot.miranda at gmail.com> a
écrit :

> Hi All,
>
>     I'v committed the core support for read-only objects, adapted from
> Clément's Pharo implementation.  Enabling read-only literals is a very
> small step from that (three methods modified in the parser, and one method
> modified in Symbol class).  I would like to do this as soon as possible,
> but it may break code.  Hence my asking for permission/sending out a
> warning before hand.  Note that the only code it will break is bad code;
> code that writes to literals.
>
> With the changes installed doing this:
>
> #(1 2 3) at: 2 put: 'nevermore'
>
> raises a ModificationForbidden exception with the message text
> "ModificationForbidden:  #(1 2 3) is read-only, hence its field 2 cannot be
> modified with 'nevermore'"
>
>
> When we added read-only object support to VisualWorks some of the
> engineering staff were of the opinion that insulating customers from the
> change was a necessary thing, and so we implemented a preference to allow
> automatic mutating of read-only literals so that customers whose code did
> modify literals could set the preference rather than fix their code.  I
> *really* don't ant to do this.  It is a lot of complication for little
> gain; the right fix is just to rewrite the code not to write to literals.
> Note that that's as easy as:
>
> #(1 2 3) copy at: 2 put: 'nevermore'; yourself
> =>
> #(1 'nevermore' 3)
>
> since copies of read-only objects are mutable.
>
> So do I have everyone's consent in changing trunk over to read-only
> literals?  If there are no strenuous complaints by tomorrow noon, PST, I
> shall effect the change.
>
> To avoid recompiling (which can produce unbound methods, etc) I shall
> change literals to be read-only via a pass over all literals and a pass
> over the Symbol table.  Hence the change should be non-invasive.  If your
> code (like probably 99.9% of all code in the system) doesn't write to
> literals you won't notice.
>
> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200311/4ced081a/attachment.html>


More information about the Squeak-dev mailing list