Hello Ross,

sorry for the private copy! Didn't check the reply address.

RB> At http://minnow.cc.gatech.edu/squeak/2176, Herbert König writes
RB> -----------------------------------------------------
RB> After refactoring I inadvertedly deleted a class and filed it in again
RB> from a previous fileout.  After that a method like

RB>   myMethod
RB>      | tempVar |
RB>       tempVar := DeletedAndRestoredClass new.
RB>       tempVar validMessageToTempVar.

RB> So here's the theory: when the class was deleted, the compiled methods

Your theory sounds plausible to me but I really am in no position to
say anything about its correctness.

Squeak (and Smalltalk) is still a bit like Christmas in the old days:
suddenly a bell rings and the Christmas tree is lighted. Didn't notice
that grandma was with us children to cover up mum and dad lighting
the candles. :-))

RB> So when you filed in the "new" class it became a new object.  The
RB> compiled methods continued to reference the old one.  So when they
RB> ran, you got an error.  Both solutions cause recompilation of the
RB> method in the presence of the new class.

The nuisance was, that all the pointer chasing and garbage collecting
shouldn't have left anything referencing the old class.

Now having better adjusted to the fact that a class as well as a
compiled method are objects too it seems plausible that the method
still had that pointer.

But then late binding should take care of that in the case of compiled
methods. I should be able to change the receiver (tempVar in this
case) of validMessageToTempVar to a different class which also
responds to validMessage... so the compiled method cannot store a
pointer to the old deleted class.

But really, I still struggle with OO, Smalltalk and Morphic and the
above is just speculation. Fun though.


RB> Comments?
Somebody really read it and thought about it :-)))


Cheers,

Herbert                            mailto:herbertkoenig at gmx.net