[squeak-dev] what is a transparent proxy?

Lauren P drurowin at gmail.com
Tue Jan 18 07:48:50 UTC 2022

Hi Chris, list,

I thought I'd add my voice in, as I've implemented pluggable proxies.

On Mon, Jan 17, 2022, 14:43 Chris Muller <asqueaker at gmail.com> wrote:

> > 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 ...
> Then there is a balance between those two, traditional "Proxy", which
> defines an explicit list of requests NOT to forward, any message not
> in the list is automatically forwarded.
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.

That explicit list of requests is the API to the proxy, the
> "metaprogramming logic" you alluded to, above.  As a Smalltalker, I
> like to have that API defined on ProtoObject with "__" or "basic"
> prefixes; i.e., #__class or #basicClass.  There could be one for each
> mirror primitive, and nothing else.  That's my preferred aesthetic,
> but the aesthetic of the Proxy API is less important to me than the
> handling semantics needed throughout the code.
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.

> > > - ProtoObject is still not yet an empty class.
> > > > For instance, stuff such as #doOnlyOnce: or #scaledIdentityHash
> should be implemented on Object only.
> That means Proxies could not be members of any HashedCollections
> without forcing reification.
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.

And it should be pushed as low into the code as it can to
> maximize usage transparency.  (I realized your definition of
> "transparent" was a function of the implementation, mine is a function
> of their usage).
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.

I'm not against a VM-based proxy system at all, the more options the better.

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

Also, could it be offered as external?

It's just that we've allowed our anticipation of it to allow
> Squeak's support for the classic Smalltalk Proxy pattern to get broken
> (because of Symbol>>#=), so we currently have no options at all.
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 *aProxy identityHash = aHash* and get something
sensible out of it.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220118/a9d3d1e7/attachment.html>

More information about the Squeak-dev mailing list