[squeak-dev] read-only literals

St├ęphane Rollandin lecteur at zogotounga.net
Mon Mar 26 08:27:23 UTC 2018

> As you found from running the tests, the few cases that
> modified literals were doing it intentionally.  My guess is that more
> read-only objects allows the VM to run a lot faster, is that right?
> But my hope was that this capability would be provided with
> granularity at the object-level, not necessarily the class level.


> Wow, Arrays and ByteArrays too?  Magma's core Buffer classes all use
> ByteArray's internally to represent and update their state.  Ouch!


> Magma uses previously-loaded ByteArray's and replaces their contents,
> field by field, via ByteArray>>#uint:at:put:.  It runs this method
> more than any other in the image -- millions and millions of times.
> The performance of this method is very important for Magma.

This definitely has to be kept possible.

>> - A second state would issue a warning to the transcript, while doing what
>> the default did.
> I'm reading that and imagining a low level primitive like
> Array>>#at:put: having a reference or signal to the Transcript that
> runs *every single time*?  That can't be true.


> In the process of raising that error, is there any danger of
> encountering a place in the debugger code which attempted to modify
> another Array, thus causing it to re-enter the original error-raising
> code to raise yet another error?  It seems like a pretty low-level
> thing to have to guard against...


> I hope we are not confusing the intermal representation of objects
> being bytes with whether those objects are literals or not.  If a
> program sees fit to modify a "literal", techincally is not a literal,
> but a variable, right?  Dave's case sounds like a true literal, but
> I'm saying I have applications which update bitmap forms in real time.
> Artists paint on SketchMorphs..  I presume you don't mean for _these_
> cases to need to make constant copies...


> Instead of introducing new assumptions and breaking old code, I
> suggest people writing which explicitly turn ON read-only'ness,  for
> the objects they want preserving legacy expectations about Smalltalk
> as well as the operation of legacy applications.  IMO, any
> introduction of immutability at the class-level should be turned off
> by default.  Make it powerful but not painful.


> It would help tremendously to know what you want to accomplish and how
> the new API works.



More information about the Squeak-dev mailing list