Hi Keith -

Nice to see you taking on all of this. I'm personally very interested in 
these improvements and (as soon as I find a bit of time) have a look at 
them for integrating this version into Croquet. Two notes though:

> The hard part about this fix is that loading the package changes the 
> instance variables of a class while it is being used. To solve this, 
> before the load, I change the class defn to the union of the before and 
> after class defnitions. I then compile the methods in the context of 
> this class. Then methods are added and removed in a tight loop, and 
> finally the class definition is changed to the final requested state, 
> after initialization.
> 
> This means that theoretically perhaps everything is now loadable, i.e. 
> it should be possible to load any package, given a couple of simple 
> precautions.

The most complex issue that I have found in doing this is when you move 
iVars up the class hierarchy. It is simple to do manually:

Object subclass: #Foo
	instanceVariableNames: ''
	...

Foo subclass: #Bar
	instanceVariableNames: 'mumble'
	...

and then (and this is where order is important):

Foo subclass: #Bar
	instanceVariableNames: ''

Object subclass: #Foo
	instanceVariableNames: 'mumble'

As far as I know this will explode pretty much everywhere and we may 
have to add a specific exception to catch the problem (it is not that 
the system can't survive the duplicate ivar temporarily it's just that 
this is really really really a bad thing to do).

In any case, I think that if you can do *that* correctly you're ready to 
take on everything else too ;-) Contrary to which ...

> The not so good news (hence the precautions): It still doesnt pass 
> Lukas'  nasty test. His test has a variable named foo, which in the 
> first case is block argument name, and in the second is an instance var. 
> Thus adding the class defn, with the inst var prior to the new methods 
> causes the old method to raise a syntax error.

... this problem really shouldn't cause a syntax error any more than 
other shadowed variables. Non-interactive compilation has always allowed 
this to go through so raising a syntax error seems inconsistent with, 
say, adding an ivar in the browser which is shadowed by a temp which 
doesn't raise a syntax error either.

Cheers,
   - Andreas