> what do you mean?

Mirror primitives exist because of proxies and why ProtoObject exist.

Best,
Marcel
Am 12.01.2022 14:03:32 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Marcel,

> This discussion looks like it affects our current ProtoObject/Proxy situation.

Not really, I think. I'm not proposing to change the dynamic forwarding pattern, what do you mean?

> maybe move those mirror primitives to ProtoObject?

Is your proposal to redefine #at: & Co. on ProtoObject under a different name, e.g., ProtoObject >> #mirrorAt:?

Technically, from my understanding, it would not a mirror primitive method in this case, just a normal primitive method. However, we probably could do this, but I am not sure why we should do this. The goal of these methods would be that no subclass ever overrides them, so we would not benefit from message dispatching. But it would keep us from reaching an empty ProtoObject class, which also means that subclasses are unnecessarily restricted in their freedom of having full control about the understood protocol.

Am I missing a point or would #mirrorAt: just be syntactical sugar in comparison to a mirror primitive method? As for the performance, a mirror primitive method requires an additional bytecode step (push) whereas #mirrroAt: might be a little bit slower in terms of method lookup, but I suppose modern VMs are good at optimizing this.

> Maybe class side?

Do you mean "ProtoObject class >> #objectAt:" etc.? Sure, we could do ... I'm not absolutely sure what makes ProtoObject class the right place for this, but sounds good. :-)

Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 12. Januar 2022 09:35:45
An: squeak-dev
Betreff: Re: [squeak-dev] Do we need to provide the mirror primitive on Context (only)?
 
Hi Christoph --

This discussion looks like it affects our current ProtoObject/Proxy situation. So ... maybe move those mirror primitives to ProtoObject? Maybe class side?

Best,
Marcel
Am 11.01.2022 22:52:36 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
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.' 

versus:

TestObject >> object: anObject eqeq: anOtherObject 
<primitive: 110>

self primitiveFailed

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. :-)

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?
* Do you consider the mirror primitive protocol a public protocol or are all senders from different classes actually abusing the protocol?
* How would you think about moving this protocol to a static place such as Context class?

Thanks in advance!

Best,
Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220112/7919ca83/attachment.html>