[squeak-dev] read-only literals
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