Andreas Raab" <andreas.raab at 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
-------------- next part --------------
Skipped content of type multipart/appledouble