>Hi,
>    we had a thread on Sugar (Smalltalk User group Argentina) about
>becomeForward: & identityHash, and we have found that Squeak does not
>behaves like other Smalltalks.
> . . .
>
>    All the other Smalltaks that we tested change the hash of the object
>that gets mutated ('string') and not the one that is used for the mutation
>('nil')
>
>    The comment of the method  Array>>#elementsForwardIdentityTo:
>otherArray says
>" ...The identityHashes remain with the pointers rather than
> with the objects so that the objects in this array should
> still be properly indexed in any existing hashed structures
> after the mutation."
>
>    So, the question is (after this long mail, sorry about it), why Squeak
>changes the hash in that way and no like the other Smalltalks?
>    Which one is the right one?

Hernan (and SUGAR thread-weavers) -

Well, you'll have to decide that for yourself.  The comment (which I wrote) answers the question you ask.  We were not trying to be like other Smalltalks, but were trying to give become the best possible behavior for the ways in which we anticipated it being used.

It wasn't clear from your enumeration, whether all your examples from other systems were forward becomes or not.  We exchange the hashes in a symmetric become (for the same reason) -- what do the other Smalltalks do in this regard?  Unfortunately this won't tell you whether anything is "right", it will only tell you the properties of their become.  I definitely feel that if one exchanges the hashes in a symmetric become, then it is consistent to forward them in a forward become.

The example with nil seems strange, I agree, but I would question the contrived example of mutating something to nil as much as I would question how the hashes are treated.  To me these operations should only be used rarely, and in ways that make sense for very specific manipulations of object identity.  Mutation of instances (adding an instance variable) is one of these, and replacement of an object with a proxy, as for remote message sends or swapping out, is another.  In each of these cases, the operation of Squeak's become avoids strange behavior if any of the objects being mutated are stored in hashed structures.  I feel this may be a more important criterion than to make sense of mutating things to nil.

For a little more history on this, when we first put (symmetric) become into Smalltalk, we were using an object memory with an object table.  The obvious implementation, which you will find in the Blue Book, was simply to exchange the data pointers of the two object table entries.  When we rebuilt Squeak on a direct-pointer object memory, we discovered the problem with becoming objects in hashed structures, and added the hash exchange in order to preserve the (nice) semantics of the original object-table pointer exchange.  When Ted and I later added forward become, we merely treated the hashes as consistently as possible with what we had done before.

There is more in this world than we have dreamed of, though and, if there's a nice clear way of looking at all this that makes better sense or works better if done another way, we'll be happy to consider changing Squeak's symmetric and forward become operations.

	- Dan