Hi all,<br>
<br>
> That means Proxies could not be members of any HashedCollections without forcing reification.<br>
<br>
Which just would be consequent if proxies do not have an own identity. This sounds to me like an optimization issue, though an important one, but not like a conceptual problem. If you want to create a proxy with its own identity, you could subclass an IdentityProxy from ProtoObject. :-)<br>
<br>
Anyway, in SimulationStudio's Sandbox, I am using a pluggable dictionary that uses mirror primitives for the hash and equality blocks. But that might only make sense in the context of simulation.<br>
<br>
> Yes, ok. But better would be to introduce a set of selectors understood<br>
> by ProtoObject and the relevant classes for checking arguments to<br>
> primitives etc, i.e. for checking concrete types. So ProtoObject and<br>
> SmallInteger could implement isBasicSmallInteger and the code would read<br>
> <br>
> *at:* index<br>
> <*primitive:* 60><br>
> index isBasicSmallInteger ifTrue:<br>
> [self basicClass isVariable<br>
> ifTrue: [self errorSubscriptBounds: index]<br>
> ifFalse: [self errorNotIndexable]].<br>
> index isNumber<br>
> ifTrue: [^self at: index asInteger]<br>
> ifFalse: [self errorNonIntegerIndex]<br>
<br>
What is your conception of "selectors understood by ProtoObject"? I don't think ProtoObject should implement these messages itself <b>(</b>it probably wasn't even able to do so). One problem that I see with both #yourself and #asInteger is that it is not obvious for the programmer of a proxy that exactly these messages must not return proxies. Maybe a single, special selector like #asNonProxy would be more helpful? Or at least #asBasicSmallInteger? As mentioned earlier, I have a proxy that automatically answers new proxies via #doesNotUnderstand:. It should be as easy as possible to distinguish between messages that may answer a proxy and messages that must answer a VM-compatible object.<br>
<br>
Other than that, #isBasicSmallInteger sounds reasonable. :-)<br>
<br>
By the way, there are some other selectors with are not proxy-safe at the moment. For instance, myProxiesBoolean ifTrue: [...] would currently raise NonBooleanReceiver. But conceptually, this is no new issue. :-)<br>
<br>
I like the overall ideas in this thread. I'm looking forward to addressing this after the release. :-)<br>
<br>
Best,<br>
Christoph<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><br>
<br>
On 2022-01-18T00:48:50-07:00, drurowin@gmail.com wrote:<br>
<br>
> Hi Chris, list,<br>
> <br>
> I thought I'd add my voice in, as I've implemented pluggable proxies.<br>
> <br>
> On Mon, Jan 17, 2022, 14:43 Chris Muller <asqueaker at gmail.com> wrote:<br>
> <br>
> > > my understanding of a "transparent proxy" is that it automatically<br>
> > forwards all requests, thus requiring special metaprogramming logic to<br>
> > reveal an object as a proxy. On the other hand, "intransparent proxies"<br>
> > would define an explicit list of requests to forward. Not sure however<br>
> > 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>
> ><br>
> In my proxy code, I have this sort of "intercepting" proxy. There are also<br>
> "before" and "after" message echo proxies, used for enforcing constraints<br>
> and running triggers. I used it to build an object system.<br>
> <br>
> 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>
> ><br>
> I agree! It needs to be very easy to use proxies. The more invisible they<br>
> are, the better. If it's too difficult or results in rather un-Smalltalk<br>
> code, people won't want to use them.<br>
> <br>
> > > > - ProtoObject is still not yet an empty class.<br>
> > > > > For instance, stuff such as #doOnlyOnce: or #scaledIdentityHash<br>
> > should be implemented on Object only.<br>
> ><br>
> > That means Proxies could not be members of any HashedCollections<br>
> > without forcing reification.<br>
> ><br>
> I disagree. They can still participate in identity hashing, as they have an<br>
> identity. More on that later. Especially, the biggest use I have found for<br>
> proxies is query result sets and efficient enumeration.<br>
> <br>
> 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>
> ><br>
> I don't like adding more things a garbage collector needs to know about,<br>
> but between MNU overhead and #== being "no lookup", a functionally<br>
> transparent proxy needs to happen at that level.<br>
> <br>
> I'm not against a VM-based proxy system at all, the more options the better.<br>
> <br>
> So long as it can be configured by object-level means, like subclasses, I<br>
> prefer VM support over "pretty transparent but has gotchas". Needing to<br>
> install the latest VM is not a big deal to me compared to reconfiguring an<br>
> image.<br>
> <br>
> Also, could it be offered as external?<br>
> <br>
> 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>
> ><br>
> The way I looked at it was, a proxy is invisible to the object system. It<br>
> doesn't exist. You can't test for it with #==, because it passes #==<br>
> through itself. But, it does have an identity, since it's a 1st Class<br>
> object, so you can ask *aProxy identityHash = aHash* and get something<br>
> sensible out of it.<br>
> <br>
> (It was a little more complicated than that. When you called #new the<br>
> outermost proxy would be a anObject, which does understand #==. None of the<br>
> internal components understood #== unless they were also anObject, which<br>
> meant you had a chain. But that's for multiple inheritance.)<br>
> <br>
> From,<br>
> Lauren<br>
> <br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220118/a9d3d1e7/attachment.html><br>
> <br>
>