[squeak-dev] enabling read-only literals...
Eliot Miranda
eliot.miranda at gmail.com
Wed Mar 11 22:38:23 UTC 2020
Hi Nicolas,
On Wed, Mar 11, 2020 at 2:35 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:
> 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.
>
That's a really good idea. I'm going to crate a class-side method in
Object class documentation that will be a release nots scratch pad. We can
delete it as we approach the final release.
>
> 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
>>
>>
>
--
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200311/f82f0272/attachment.html>
More information about the Squeak-dev
mailing list
|