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