> After getting the report about this problem from the 
> SqueakEnd, I have been working on the problem too. Once I've 
> tested that my result works, I will post it.

Great!  Thanks...I'll wait a bit then.

> So I'm working on an enhancement that will get the superclass 
> ordering right when possible, but there are certain problems 
> with this so that this only works under special conditions. 
> That means that the circularity must be dealt with when the 
> module is saved, not on loading it. Luckily it is usually 
> easy to apply this technique on saving however.

What do you have to do when saving?

> I don't really understand how such a scheme would work? What 
> I think be needed would be a way to fix superclass references 
> "in retrospect", similar to how Undeclared binds references 
> in retrospect. It would be rather easy to make the installer 
> go through a list of classes and fix them up when everything 
> is loaded.

I was just thinking that you would only need to gather up everything
that needed to be activated, and activate it in an order that it
wouldn't break.  However, fixing superclass references in retrospect
might be more robust and easier to implement.

So, if I understand correctly, co-dependence will be allowed (maybe this
has been covered before, I can't remember)?

- Stephen