Andreas Raab" andreas.raab@gmx.de writes:
To understand the effect have a look at the implementations of WeakKeyAssociation>>key and WeakKeyAssociation>>key: - this should make it clear that WeakKeyAssociations store their key in form of a weak array so that it can be garbage collected. Thus there isn't anything broken, except from the interpretation of the key iVar.
I figured out what was going wrong - one last WeakKeyAssociation object of the old kind (with the array) was being created by the act of patching in the new kind of WeakKeyAssociation. (Changing the class hierarchy created an obsolete subclass, which had to be weakly remembered...)
However, by the time that this errant object was created, the method dictionary of its class had been zapped (Behavior>>canZapMethodDictionary always returns true; perhaps it should check to see if there are still any instances or the potential to create any). Thus, this object didn't behave correctly, because its key method was the one inherited from LookUpKey.
By doing a double renaming I at last have a change set for this refactoring that can be loaded, at least, it loads fine into a clean 3.7beta #5969.
This changeset passes the tests that I posted a couple of weeks ago.
Andrew