[squeak-dev] Do we need to provide the mirror primitive on Context (only)?
Christoph.Thiede at student.hpi.uni-potsdam.de
Thu Jan 13 23:43:33 UTC 2022
thank you for the reply! :-)
Just one follow-up question: If you say the mirror primitives should actually not be used outside of simulation, what would in your eyes be the right way to implement tools like the basic inspector, which does not want to follow any proxy redirections, too? As I can see it, the only alternative to using mirror primitives in this case would be a special protocol on ProtoObject ("#noMirrorClass", "#noMirrorEqeq:", etc.) which connects to the normal primitives. But this would come with the disadvantage of an unclean ProtoObject protocol, so it does not appear desirable to me either. It's a tricky design problem ...
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
Gesendet: Donnerstag, 13. Januar 2022 23:58:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Do we need to provide the mirror primitive on Context (only)?
On Jan 11, 2022, at 1:52 PM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
Hi Eliot, hi all,
as I have learned from your great explanation about stack frame states and marriage last year, using "thisContext" in your code is more expensive than one might assume naively when thinking of it as a simple variable. This also means that using "thisContext" for invoking a mirror primitive is (unnecessarily?) slow:
[thisContext object: World eqeq: World] bench. '28,000,000 per second. 35.8 nanoseconds per run. 19.13235 % GC time.'
TestObject >> object: anObject eqeq: anOtherObject
obj := TestObject new.
[obj object: World eqeq: World] bench '58,900,000 per second. 17 nanoseconds per run. 0 % GC time.'
Twice as fast!
I am wondering whether it would be useful to copy or move the mirror primitive protocol to another place, maybe on the class-side of Context, given the number of senders to some mirror primitive methods which are different from Context. In particular, SimulationStudio makes heavy<https://sourcegraph.com/search?q=context:global+thisContext+object+repo:LinqLover/SimulationStudio&patternType=literal> use of them, but the BasicInspector, Squot, and some other tools use it, too. :-)
I suppose so. I would tolerate the slow down. This is protocol that completely sidesteps encapsulation so its use should be as encapsulated as possible, and IMO putting the protocol on a class makes it a little too public. It’s also unnecessary; see below.
So here are my questions:
* Would this be a legitimate use of the mirror primitives or is the (implicit) contract that the receiver must be a context instance or even a context instance on the current stack?
For me it makes sense that the protocol is on the instance side of Context. Both conceptually (in the VM) and in execution simulation it is Contexts that obey (execute) bytecode and in doing so sidestep encapsulation.
* Do you consider the mirror primitive protocol a public protocol or are all senders from different classes actually abusing the protocol?
No; the mirror protocol is provided to allow Context to implement execution simulation correctly. As we know, relying on messages to objects results in completely broken results when using proxies.
* How would you think about moving this protocol to a static place such as Context class?
I think it’s neither desirable nor necessary. If Simulation Studio needs to avoid the overhead of Context creation if can surely simply instantiate a Context and use it throughout to invoke the mirror protocol. Nothing says that one has to use thisContext; “Context basicNew objectClass: nil” also works, hence (eg in Simulation Studio)
myMirror := Context receiver: …
| actualClass |
actualClass := myMirror objectClass: someThing
will work just fine.
Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev