Hi Bob, first of all, thanks so much for your support!

Notwithstanding your scenario for a moment, I was coming from the idea that
SOMETHING is going to need to be rehashed anyway once you becomeForward:. 
Either all Sets that reference the receiver (if we didn't copy the hash bits),
or all Sets that reference the argument (the current case, because the hash
bits are copied).

Your argument is a "usability" argument.  That, based on your scenario being
the most common scenario to use becomeForward:, there should be NO hashed
collections that contain the argument at the time you send becomeForward:,
OTHER than the global Smalltalk or the SymbolTable (and possibly other system
objects).

And, since it helps tremendously with the tricky problem of knowing which Sets
and Dictionaries to rehash, I must say that I'm starting to come around and
find myself "getting on board" with you about it.

One reason it has taken this long for me, perhaps, is that of 99% of
applications in MY life, 99% of their domain classes don't, and shouldn't,
override = and hash.  It is a poor practice.  Additionally, I tend to use
regular Dictionaries instead of IdentityDictionaries.  Due to not overriding =,
it ends up hashing based on their identity anyway.

But that is through Dictionary>>at:put: sending #hash, not #identityHash. 
Since hash is not implemented in ProtoObject, it causes reification of my proxy
before it can get into the Dictionary in the first place.

So I typically never have any proxies in any hashedCollection, nullifying, for
me, the benefit of not having to rehash.  Yet, at the same time, introducing
the very real and common problem of an object referencing a Symbol that CAN
very easily be proxied out.  When that is materialized, it causes the very
important SymbolTable and, sometimes, Smalltalk collections to get confused.

Ok (sigh), so I think I can progress forward if, when I materialize a Symbol,
I'll just be sure to rehash the SymbolTable (and Smalltalk, if necessary). 
That should work, right?  It takes nearly 2 seconds (rats!).

There's also Avi's suggestion of not allowing the server to proxy a Symbol.  It
looks like that's still on the table for me.

Best Regards,
  Chris

=============
Bob Arning wrote:

Now why don't I think it's a bug? First, we are talking about #identityHash 
here, not just #hash. ProtoObject implements #identityHash with the comment "Do

not override". 

My basic thought is that
	a becomeForward: b
would most likely involve an 'a' that has existed for some time and a 'b' that 
has just been created (like in the last few microseconds). Hence, it it more 
important to retain the identityHash of 'a' than that of 'b'.

A scenario (not unlike things I've encountered in real-life Smalltalk <-> 
database work):

I have a collection of Persons.
Each person has a name which is a String (not proxied in this implementation).
Each person has an employer which is a proxy until reified.
I wonder how many of these persons work for the same employer, so I do:

bossToWorker _ IdentityDictionary new.
persons do: [ :each |
	(bossToWorker 
		at: each employer 
		ifAbsentPut: [OrderedCollection new]) add: each.
].

Up until this point, the only messages I have sent to an Employer are 
#identityHash and #==, neither of which would trigger reification, so the
employers are 
distributed according to the identityHash they have at the moment (although 
some of them could have been reified by earlier operations). NOW, we start
poking 
into these employers. We ask them questions that the proxies cannot answer, so 
new objects are created and filled with data and then

	oldProxyObject forwardBecome: realEmployerObject

Unless realEmployerObject inherits the identityHash from oldProxyObject, my 
IdentityDictionary is going to start acting funny.

This seems like a reasonable example to me - where do we diverge?


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