Hi Christoph --

> we should at least have a conceptual alternative in mind.

Please look through the history of squeak-dev and vm-dev. You will find several thoughts about this in there. At best, you can compile a list of interesting threads from the past and post them here. Thanks. :-)

Best,
Marcel
Am 14.01.2022 16:23:17 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Marcel, hi Eliot,

I am wondering how an ideal solution for handling proxies in higher-level Squeak tools would look for you. If we treat the use of mirror primitives in these places as a code smell, we should at least have a conceptual alternative in mind. It feels like deliberately increasing technical debt in the system if we don't have an alternative. ;(

Best,
Christoph

---
Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]

On 2022-01-14T10:18:51+01:00, marcel.taeumel at hpi.de wrote:

> Hi Christoph --
>
> >  what would in your eyes be the right way to implement tools like the basic inspector
>
> Until we can improve proxy representation/implementation in Squeak, I don't think there is a better way to provide some proxy compatibility in BasicInspector. But we might want to treat any use of those mirror-primitives in tools such as BasicInspector as a code smell.
>
> Best,
> Marcel
> Am 14.01.2022 00:43:45 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
> Hi Eliot,
>
> 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 ...
>
> Best,
> Christoph
> 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)?
>  
> Hi Christoph,
>
> 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.' 
>
> 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!
>
> Quite so.
>
> 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)
>     initialize
>         myMirror := Context receiver: ? 
>
>     someMethod: someThing
>          | actualClass |
>          actualClass := myMirror objectClass: someThing
>
> will work just fine.
>
>
> Thanks in advance!
>
> HTH
>
>
> Best,
> Christoph
>
> Eliot
> _,,,^..^,,,_ (phone)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/5a1cb667/attachment.html>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/bda8928b/attachment.html>