Hi Craig, Hi Chris,

I'm myself a mainly VM-agnostic Squeaker right now, would you like to convince me why a VM-based proxy would be the better way? :)

As a general thought, I appreciate the simplicity and genericity of Smalltalk very much, which allows you for solving almost all problems in the image, without needing to change the VM/the interpreter/whatever else, just by expressing your problem in the code being executed. VMs are awesome to optimize these solutions significantly, but in many cases, we might not actually to look/work behind the scenes for it. Why do you recommend VM support for proxies? :)

I'm also thinking about "shippability", if I need to exchange the VM to run my Smalltalk application, this would a severe limitation and reason for compatibility issues between multiple softwares, unless the VM is completely pluggable from the image side.

Playing advocatus diaboli:

> The only downside is that those who only understand Smalltalk and not the secret innards of the VM cannot realistically participate in Squeak anymore if they wish or need to use the classic Proxy pattern.  We broke the code and also legacy systems for that.

Well, the connection to the VM could be encapsulated in some particular class in the Trunk which would handle all the secret details. Any project that needs a proxy could just inherit from such a VMProxy class. Couldn't this work?

Re Symbol >> #=:

> So what about when aVMProxy instance is passed in?

One possible answer would be that VM proxies would not have its own identity, so "self == aSymbol" would answer true. See my previous answer about discussing the consequences of this decision. :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2022-01-15T18:51:00-06:00, asqueaker at gmail.com wrote:

> Hi Craig,
> 
> >       Indeed, none of our code should be proxy-aware.
> 
> I certainly would agree with the statement, "it would be nice if none
> of our code needed to be proxy-aware," but I don't yet understand how
> it's possible, regardless where the implementation details are handled
> (VM or image).  As a VM expert, I can appreciate you preferring to use
> VM-based proxies.  The only downside is that those who only understand
> Smalltalk and not the secret innards of the VM cannot realistically
> participate in Squeak anymore if they wish or need to use the classic
> Proxy pattern.  We broke the code and also legacy systems for that.
> 
> Which is why I keep bringing up just this one example on Symbol
> and hoping someone can explain it to help me get unstuck.  Would you
> follow its code with me, line by line, below?  Let's pretend the
> receiver is the symbol #size, and the argument, aSymbol, comes in as
> an instance of MyProxy, which refers to an Integer oid that ultimately
> will reify to the receiver object (#size)).
> 
> It's easy to see why the code no longer works for the traditional Proxy pattern:
> 
>    = aSymbol       "<------ aSymbol comes in as a MyProxy instance"
>         self == aSymbol ifTrue: [^ true].       "<---- false, continue"
>         aSymbol isSymbol ifTrue: [^ false].  "<----- true, return false.  BUG!"
>         "Use String comparison otherwise"
>         ^ super = aSymbol
> 
> So what about when aVMProxy instance is passed in?  I'm so used to
> normal Smalltalk-think, I'm not even able to think about WHEN or HOW
> the VM would perform it's magic handling of the incoming VMProxy
> instance to make this work.  I guess this is a trade-off -- we don't
> have to think about Proxy's, but we have to know about and think about
> VM magic.  I'm willing to try, but I don't even know where to begin.
> Would you help?
> 
> Regards,
>   Chris
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220116/b597f48b/attachment.html>