<div dir="ltr"><div dir="ltr">Hi Eliot,<div></div><div><br></div><div></div><div>Can  ModificationForbidden be resumed?  I certainly hope so.  Magma's own WriteBarrier has one place where it dynamically compiles a literal in a method for the sole purpose of providing one extra reference slot needed for the framework.  This is a useful feature in a general sense, something I'd hate to see lost.  Yes, I understand it's "bad code" to modify a literal, just like using "become:" (which it also uses), but for frameworks that need to work slightly under the hood, these hacks can be very useful when one knows what they're doing.</div><div><br></div><div>Unfortunately, I don't think the VM-based WriteBarrier can work for Magma due to its "global" nature.</div><div><br></div></div><div class="gmail_quote"><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"><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></div></div></div></div></blockquote><div><br></div><div></div><div>I don't think we need a global preference as much as just let it be #isResumable.  Can we do that?</div><div><br></div><div>Best,</div><div>  Chris</div><div><br></div></div></div>