> Let me give you my side of it.
>
> The reason I started mucking with the association code is that it is 
> BROKEN.  How?  Run the tests on the existing image and you will see. 
> There are many missing methods in the various "special" association 
> classes, because they do not inherit from Association, but from 
> LookUpKey.
>
> I didn't invent ReadOnlyVariable binding.  But it is there, and it us 
> used.  Unfortunately, because the inheritance hierarchy is presently 
> wrong, ReadOnlyvariableBindings appear in the debugger like 
> LookUpKeys, not like associations.  I lost many hours that way.
>
> So I fixed it.  But I don't like to patch, I like to do it right.  So 
> I wrote tests, made the existing code fail, and then wrote new 
> classes, which made the tests pass.  I thought that this was the 
> "good" way to do it.
>
> Then I had to make a changeset so that this stuff would get out into 
> the image.  This was a big job, because of all of the special case 
> code that was trying to stop someone from fixing these bugs. Building 
> the change set took weeks.  The system code is simple and robust, but 
> the change set is not.  It was built with bit tweezers (a text editor) 
> because Squeak has no facilities for ordering changes or committing 
> changes atomically.
>
> Then I hoped that it would get into the image.  I have had 
> conversations with several different harvesters about the whys and the 
> wherefores of these changes.  But they never get into the image. We 
> are now two versions away from the Squeak where I made this changeset 
> work, and so I'm nor surprised that it doesn't work for you.
>
> My suggestion from this are:
>
> (1) If we need special case code to stop things from being recompiled, 
> there should be a way to turn it off.
>
> (2) I was told that the right way to document the need for changes is 
> to create a failing test set and submit it.  I did this in this case, 
> but it has apparently been lost.  So, we should decide what IS the 
> right way to document the need for a change.
>
> (3) There should be an accelerated path for getting "delicate" change 
> sets like this into the image.
>
> 	Andrew
>
> -- 
>
>    Prof. Andrew P. Black                     		Home: +1 503 629 5495
>    Department of Computer Science,		Cell: +1 503 803 1669
>    Portland State University			Office: +1 503 725 2411
>    Portland, Oregon, USA		  	http://www.cs.pdx.edu/~black
>