<div dir="ltr"><div><div>Since the Compiler will decide whether literals are to be made readOnly or not,<br></div><div>it's there that the preference should act, if we ever need a preference.</div><div><br></div>Mofifying a literal intentionally is a way to keep some state around at method level.<br></div><div>It happened to work, but it's not a supported feature and there never were any guaranty that such behavior would be preserved.<br></div><div>For example, a Compiler might as well avoid duplicating literals and share them across CompiledMethod.<br><br></div><div>An application relying massively on such unsupported feature could use own Compiler.<br></div><div>Or we could introduce kind of compiler directives in annotations like Pharo did.<br></div><div>But I wonder if the complication is worth.<br></div><div>Aren't there many other ways to hold states?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-26 10:27 GMT+02:00 Stéphane Rollandin <span dir="ltr"><<a href="mailto:lecteur@zogotounga.net" target="_blank">lecteur@zogotounga.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As you found from running the tests, the few cases that<br>
modified literals were doing it intentionally.  My guess is that more<br>
read-only objects allows the VM to run a lot faster, is that right?<br>
But my hope was that this capability would be provided with<br>
granularity at the object-level, not necessarily the class level.<br>
</blockquote>
<br></span>
+1<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Wow, Arrays and ByteArrays too?  Magma's core Buffer classes all use<br>
ByteArray's internally to represent and update their state.  Ouch!<br>
</blockquote>
<br></span>
+1000<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Magma uses previously-loaded ByteArray's and replaces their contents,<br>
field by field, via ByteArray>>#uint:at:put:.  It runs this method<br>
more than any other in the image -- millions and millions of times.<br>
The performance of this method is very important for Magma.<br>
</blockquote>
<br></span>
This definitely has to be kept possible.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- A second state would issue a warning to the transcript, while doing what<br>
the default did.<br>
</blockquote>
<br>
I'm reading that and imagining a low level primitive like<br>
Array>>#at:put: having a reference or signal to the Transcript that<br>
runs *every single time*?  That can't be true.<br>
</blockquote>
<br></span>
+100<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the process of raising that error, is there any danger of<br>
encountering a place in the debugger code which attempted to modify<br>
another Array, thus causing it to re-enter the original error-raising<br>
code to raise yet another error?  It seems like a pretty low-level<br>
thing to have to guard against...<br>
</blockquote>
<br></span>
+1<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I hope we are not confusing the intermal representation of objects<br>
being bytes with whether those objects are literals or not.  If a<br>
program sees fit to modify a "literal", techincally is not a literal,<br>
but a variable, right?  Dave's case sounds like a true literal, but<br>
I'm saying I have applications which update bitmap forms in real time.<br>
Artists paint on SketchMorphs..  I presume you don't mean for _these_<br>
cases to need to make constant copies...<br>
</blockquote>
<br></span>
+1000<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Instead of introducing new assumptions and breaking old code, I<br>
suggest people writing which explicitly turn ON read-only'ness,  for<br>
the objects they want preserving legacy expectations about Smalltalk<br>
as well as the operation of legacy applications.  IMO, any<br>
introduction of immutability at the class-level should be turned off<br>
by default.  Make it powerful but not painful.<br>
</blockquote>
<br></span>
+1<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It would help tremendously to know what you want to accomplish and how<br>
the new API works.<br>
</blockquote>
<br></span>
Indeed.<br>
<br>
<br>
Stef<br>
<br>
</blockquote></div><br></div>