<div dir="ltr"><div>Hi Eliot,</div><div>IMO you can proceed, it's better to introduce this kind of changes in early stages of the release cycle.</div><div>Anyway, it's 6.0, not 5.x ;)</div><div><br></div><div>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).<br></div><div>It's possible I also saw that trick once or twice, but its really an abuse of undocumented and implementation defined behavior.</div><div>Anyway, we can decide to later add a defaultAction or better let that responsibility to "clients" unwilling to change their code.</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 11 mars 2020 à 22:10, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi All,<div><br></div><div>    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.</div><div><br></div><div>With the changes installed doing this:</div><div><br></div><div>#(1 2 3) at: 2 put: 'nevermore'<br></div><div><br></div><div>raises a ModificationForbidden exception with the message text "ModificationForbidden:  #(1 2 3) is read-only, hence its field 2 cannot be modified with 'nevermore'"</div><div><br></div><div><br></div><div>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:</div><div><br></div><div>#(1 2 3) copy at: 2 put: 'nevermore'; yourself</div><div>=></div><div><div>#(1 'nevermore' 3)</div></div><div><br></div><div>since copies of read-only objects are mutable.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br><div dir="ltr"><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></div></div></div></div>
<br>
</blockquote></div>