Stephen,

Notwithstanding the fact that I have only used proxies naively, and
certainly not for something as complicated as ghosting a persistent
object, it would entail a certain identity/equality conundrum, wouldn't
it?  This same problem seems to apply to distributed objects, especially
when considering multiple paths to a remote object for fault tolerance. 
2 references to the same object should be identical and equal, but
comparing the paths themselves should only be equal and not identical.

My philosophy on proxies is that composition is better than replacement
with become:.  I like seeing the intention in my explorer, however
handling various other aspects in special ways may actually increase the
complexity beyond the usefulness of composing the proxy and subject
(events, transaction states, locks, GC).  Didn't you do the trampoline
work?

The most interesting thing about having a proxy which processes
Squeaks Message objects is that we can redirect lookup to a pseudo-Class
which can implement Capabilities and Aspects.

What constitutes the most basic and complete Proxy?  What protocol
cannot be redirected to the subject without breaking parts of the
environment (for instance, opening an Inspector or Explorer on them)?

cheers,
Rob

Stephen Pair wrote:
> 
> Robert Withers wrote:
> 
> > I don't typically use become: either..
> 
> When building proxy systems in the past (mainly for persistent object
> storage), I've used the become technique quite effectively.  The code could
> become (no pun intended) quite tricky and difficult to debug and maintain
> however.
> 
> I'm looking at a scenario with Squeak where I'll need to once again use a
> proxy scheme for persistent object storage.  I've essentially ruled out the
> use of become because of Squeak's lack of an object table, and the resulting
> in-efficiency of using become.
> 
> When using become, the up-side is that the real object and a proxy for that
> object will always share the same identity (you either have one or the other
> in the image at a given time).
> 
> What is the best approach for dealing with this "identity crisis" when using
> #become: is not an option?  My first thought is that the only reference to
> the "real" object would be from it's proxy, and *all* outside references
> would always go through the proxy.
> 
> Any words of advise?
> 
> Thanks,
> Stephen

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!