<div dir="auto"><div>Hi Chris, list,</div><div dir="auto"><br></div><div dir="auto">I thought I'd add my voice in, as I've implemented pluggable proxies.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Jan 17, 2022, 14:43 Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> my understanding of a "transparent proxy" is that it automatically forwards all requests, thus requiring special metaprogramming logic to reveal an object as a proxy. On the other hand, "intransparent proxies" would define an explicit list of requests to forward. Not sure however whether this is a useful classification ...<br>
<br>
Then there is a balance between those two, traditional "Proxy", which<br>
defines an explicit list of requests NOT to forward, any message not<br>
in the list is automatically forwarded.<br></blockquote></div></div><div dir="auto">In my proxy code, I have this sort of "intercepting" proxy. There are also "before" and "after" message echo proxies, used for enforcing constraints and running triggers. I used it to build an object system.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That explicit list of requests is the API to the proxy, the<br>
"metaprogramming logic" you alluded to, above.  As a Smalltalker, I<br>
like to have that API defined on ProtoObject with "__" or "basic"<br>
prefixes; i.e., #__class or #basicClass.  There could be one for each<br>
mirror primitive, and nothing else.  That's my preferred aesthetic,<br>
but the aesthetic of the Proxy API is less important to me than the<br>
handling semantics needed throughout the code.<br></blockquote></div></div><div dir="auto">I agree! It needs to be very easy to use proxies. The more invisible they are, the better. If it's too difficult or results in rather un-Smalltalk code, people won't want to use them.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > > - ProtoObject is still not yet an empty class.<br>
> > > For instance, stuff such as #doOnlyOnce: or #scaledIdentityHash should be implemented on Object only.<br>
<br>
That means Proxies could not be members of any HashedCollections<br>
without forcing reification.<br></blockquote></div></div><div dir="auto">I disagree. They can still participate in identity hashing, as they have an identity. More on that later. Especially, the biggest use I have found for proxies is query result sets and efficient enumeration.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And it should be pushed as low into the code as it can to<br>
maximize usage transparency.  (I realized your definition of<br>
"transparent" was a function of the implementation, mine is a function<br>
of their usage).<br></blockquote></div></div><div dir="auto">I don't like adding more things a garbage collector needs to know about, but between MNU overhead and #== being "no lookup", a functionally transparent proxy needs to happen at that level.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not against a VM-based proxy system at all, the more options the better.</blockquote></div></div><div dir="auto">So long as it can be configured by object-level means, like subclasses, I prefer VM support over "pretty transparent but has gotchas". Needing to install the latest VM is not a big deal to me compared to reconfiguring an image.</div><div dir="auto"><br></div><div dir="auto">Also, could it be offered as external?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's just that we've allowed our anticipation of it to allow<br>
Squeak's support for the classic Smalltalk Proxy pattern to get broken<br>
(because of Symbol>>#=), so we currently have no options at all.<br></blockquote></div></div><div dir="auto">The way I looked at it was, a proxy is invisible to the object system. It doesn't exist. You can't test for it with #==, because it passes #== through itself. But, it does have an identity, since it's a 1st Class object, so you can ask <i>aProxy identityHash = aHash</i> and get something sensible out of it.</div><div dir="auto"><br></div><div dir="auto">(It was a little more complicated than that. When you called #new the outermost proxy would be a anObject, which does understand #==. None of the internal components understood #== unless they were also anObject, which meant you had a chain. But that's for multiple inheritance.)</div><div dir="auto"><br></div><div dir="auto">From,</div><div dir="auto">Lauren</div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>