I understand doctor, #become is a message that can cause some serious pain in
normal application programs.  :-)  But since proxies are a required part any
object database framework, I NEED a working becomeForward:.

The last 26 months of daily work on this project has brought me to 99%
completion of this great ODBMS.  Unfortunately, this bug has me halted in my
testing right now, so I have to do whatever it takes to get it fixed so I can
finish up and release this sucker.

So you're saying that the hash value of myProxy (which is merely its
identity-hash) is being copied in to the Symbol's slot in the object header
that holds its identity-hash value, effectively changing its identity-hash
value.  Not only is the change in the Symbol's hash value causing it to become
"lost" in the hashed collection, but after a rehash, it resides in *both* its
old and its new location?  Thus causing a straight-through enumeration to
encounter it twice?

I'm a little unsure as to why *anything* in the object-header would be changed
other than the pointer to the old object to now point to the new..  You said it
was being copied in the "wrong direction," but I'm unsure why hash value would
need to be copied at all, in any direction.

Can you help point me to the code where the problem is?  I've never been into
the Slang before..

Thanks Bob!

PS - What does AFAICT mean?

> The major problem, AFAICT, is that the the hash is copied in the wrong
> direction in Squeak. This can be fixed. Otherwise, the same sorts of problems
> will arise in any Smalltalk, like:
> 
> 	s _ IdentitySet new.
> 	s add: a; add: b.
> 	a becomeForward: b.
> 
> Now an important invariant is violated - the same object appears twice in a
> set. Whose fault is this or, better, how to correct it?
> 
> Patient: Doctor, it hurts when I do this.
> Doctor: Don't do that.
> 
> Cheers,
> Bob


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com