Hi all!<br>
<br>
I am working on a new super exciting simulation project that makes extensive uses of transparent proxy objects via ProtoObject and dynamic forwarding (#doesNotUnderstand:). Usually, my current experiments with dynamic forwarding work very well through the entire system, but I identified two kinds of situations in which proxies are not handled transparently:<br>
<br>
<b>1. Parameters that are passed to the VM for a primitive</b> - e.g., <font color="#000080">#</font><font color="#000000">(</font><font color="#800000">1</font><font color="#000000">)</font><font color="#000000"> </font><font color="#000080">at:</font><font color="#000000"> </font><font color="#000000">(</font><font color="#FF0000">MyFancyProxy</font><font color="#000000"> </font><font color="#000080">on:</font><font color="#000000"> </font><font color="#800000">1</font><font color="#000000">)</font> will not work because most VM primitives expect value objects and do not honor dynamic forwarding. That's not ideal, but I can deal with it, because in my situation proxying immediate objects does not make great sense anyway. (Alternatively, I could also adjust the fallback implementation in <font color="#000000">Object</font><font color="#000000"> </font><font color="#000080">>></font><font color="#000000"> </font><font color="#000080">#at:</font> to "unpack" the proxy.)<br>
<br>
<b>2. Inlined message sends - such as #ifTrue: or #==.</b> While the first one is only sent to value objects (booleans) only and I thus can filter them out easily, the second is a message that can be sent to any object of any class, and the fact that one cannot actually override #== or #~~ is pretty much annoying while working with proxies.<br>
Here is my question: What would be the simplest way to disable inlined message sends for these selectors? I expect to write something like a simple patch to the encoder, followed by a recompilation of all methods in the image for my project.<br>
And do you have any idea how significantly this would decrease the overall performance of Squeak?<br>
Last but not least, if the performance overhead is insignificant, how would you think about disabling these inlined message sends in the Trunk as well? IMHO two of Squeaks most important characteristics are its powerful metaprogramming features and its suitability for research purposes. From this perspective, eliminating these VM-hardcoded implementation could be really helpful.<br>
<br>
Thanks in advance!<br>
<br>
Best,<br>
Christoph<br>
<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font>