Chris,

I've been thinking about the hash question and think maybe the current implementation is correct. The way you would use it is...

	someProxyObject _ universe getMinimalInfo.

Time passes and more information is available

	theRealObject _ universe getFullInfo.

Now you'd like to begin using theRealObject where you had been using someProxyObject

	someProxyObject becomeForward: theRealObject.

Which is great as all references now point to the real object and...
the real object has THE HASH BITS FROM THE PROXY OBJECT - this is good, because you may have already put someProxyObject in a hashed collection and you would expect to find theRealObject occupying the same slot after the become.

How does this differ from the example you gave? In this example, theRealObject was a brand-new object and had not been stored in a hashed collection yet. So changing its hash was ok. In your original example #MyTestClass HAD been stored in hashed collections (the symbol table and Smalltalk), thus it was a big problem that the hash changed.

So the question is, how realistic is the example you gave initially? It seems a bit more hypothetical than actual. Maybe we need to look more closely at what you really need to do.

Cheers,
Bob



On Fri, 17 May 2002 11:02:26 -0700 (PDT) Chris Muller <afunkyobject at yahoo.com> wrote:
>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..