> Now, if there is a different suggestion, that we make methods read-only, I would support that.


If you are talking about making methods read-only, are you also intending to deprecate #literalAt:put:? I'm asking because this one is actually used by the workspace to create dynamic bindings.


However, I have been never convinced why we need to store these bindings in the method itself. The debugger does not even support that (you can neither view these bindings in one of the debugger's inspectors, nor they are styled correctly) what is a pity IMHO. Can we give each workspace a uniclass instance as doItReceiver, and store dynamic bindings as its instance variables instead of method literals? This change should not break anything important (retained behavior: all codes that are run in one workspace access the same variables), but it would

a) improve the user experience as you could watch the variables in the debugger's inspector like regular variables, and

b) allow us to make methods completely read-only.

Or would it be too confusing if [self class] in a Workspaces printed out something like "Object17" or "UndefinedObject17" rather than "UndefinedObject"?


PS: Sorry for abducting this topic into the domain of Tools! :-)


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
Gesendet: Freitag, 3. April 2020 20:53:40
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Modifying a method's bytecodes ... is it supported?

Hi Marcel,

On Fri, Apr 3, 2020 at 10:02 AM Marcel Taeumel <marcel.taeumel at hpi.de<mailto:marcel.taeumel at hpi.de>> wrote:
Hi, all!

Are a method's bytecodes virtually read-only? There is no ModificationForbidden at the moment ...

Modification is allowed, and in a StackInterpeeter, will be obeyed immediately,, BUT one cannot simply modify bytecodes and expect things to change.  Because of the JIT one also has to flush any and all ached VM state, in particular generated code, via CompiledCode>>voidCogVMState.  We made heavy use of this facility at Cadence where we modified bytecodes to install line-specific break-points (don't ask ;-) ).  I'm cc'ing Bob to see if you, Bob, can remember where the tests are.  I've looked in MethodMassage and there is only a simply test.  But IIRC we had a full breakpoint test at one stage.

Now, if there is a different suggestion, that we make methods read-only, I would support that.  Then we could formalize the use of CompiledCode>>voidCogVMState, something like if one attempted to modify a method, there would be an exception that one could proceed through and somehow voidCogVMState would be invoked before resetting the method back to being read-only.


Note that in ViualWorks methods are also not read-only (or weren't in 2007 when we did the immutability work).  I think methods *should* be read-only, but in the Squeak context that means making them writable while their source pointers are updated, etc.

> Best,
> Marcel

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200403/91a06ba2/attachment.html>