Ned Konz wrote:

> Sure. One example would be in a system where you had proxy objects
> representing, say, objects that were out in disk files. These would be
> placekeepers (allowing existing objects to maintain their references) and
> could load on demand. However, when I re-load an object that I had a proxy
> to, I want all the other objects that pointed to the proxy to now point to
> the real object.

Ah. I see what you're getting at now.  I'm sure this is incredibly naive, 
but couldn't this be handled by having a proxy for each of your proxies? 
Ie, the second-level proxy never changes and that's what all the other 
objects have references to.  You then change the second-level proxy object 
to refer to the new object.

In fact, I thought there was already a class in Ruby called something like 
Delegator that would do what you're talking about.

As I say, I've probably still not understood the issue you're trying to 
address, so perhaps I'll just watch the discussion unfold and may pick up 
on it eventually.

> This is a trivial operation on the old Smalltalks that used double
> indirection to get to objects; it amounted to swapping two values in the
> object table. It's considerably more costly when object references are
> implemented as direct memory pointers, as you may have to hunt down all
> the old pointers.

Yes, double indirection is a wonderful thing.  It does waste a bit of 
memory, of course.  That's why I like the idea of having a class that 
transparently provides an extra level of indirection that you can use when 
you need it.

Now, I'll just go and lurk :-) ...