Nathanael,

> Nevertheless, I think that there is also a problem caused by 
> the circular meta-structure. This does not occur when you add
> a new instance variable to 'Class', but it occurs when you change
> the superclass of 'Class'. (In fact, this is what I did in my image).

Ah, yes. That's slightly different ;-)

> What happens is that the ClassBuilder wants to change the 
> shape of 'Class' and it therefore calls 'ClassBuilder>>mutate:to:'
> for all the subclasses. At one point, 'Class class' is mutated and
> this reshapes its instance 'Class'. (Your fix made this work
> correctly). After all the subclasses are reshaped,
> the ClassBuilder calls 'ClassBuilder>>update:to:' to update 
> 'Class' itself. But since the instance has already been touched
before,
> it is in an inconsistent state and it brakes.

Hm. I still think that this should work. Simply because when we reshape
a class we temporarily have two classes X and X'. X is the original one
and X' the new superclass for all the subclasses of X. Only when all
subclasses of X have been converted X is changed into X'. For your Class
example, this would mean we first change the shape of Class into Class'
then recompile the entire metaclass hierarchy (which will update both
Class class and Class' class) and then - after all this is done - we
change Class into Class'. Since the recompilation process ought to be
atomical with respect to updating subclasses there should be no visible
difference for the class builder.

At least that's the theory ;-)

> This is the reason why I modified the ClassBuilder so that it 
> changes 'Class class' and its instance at the end of the process
> and not in the middle. This ensures that 'Class' is still in the
> expected shape when it is used as an argument to 
>'ClassBuilder>>update:to:'. (With other words, my change
> makes sure that 'ClassBuilder>>update:to:' is called first 
> with the argument 'Class' and then with 'Class class' instead of doing
> it the other way round). Considering the circular meta-structure of
Squeak
> this seems a reasonable way to do it without applying too many dirty 
> tricks. What do you think?

Everything that works is reasonable here :-) My interest is more on the
theoretical side - it just "ought to work" and I am wondering why it
doesn't.

> Okay, now let me come back to the issue of the strange 
> obsolete classes sored in the SystemDictionary.

That's clearly some bug.

> 1) Why do these classes not appear as obsolete subclasses of their
> superclasses?

I have no idea whatsoever. This should never be the case.

> 2) Why are these classes stored in the SystemDictionary (with 
> strings as keys!)?

Again, I have no idea. This just absolutely shouldn't be the case.

> 3) Shouldn't we change this so that the class hierarchy is 
> consistent (means if a class B has a superclass A, then B is
> either a regular subclass or an obsolete subclass of A).

By all means, yes! However, we should also change it so that we never
even get into the inconsistent state - if we just new how it got there
in the first place...

> Of course, I can modify the line (*) in the method
> 'ClassBuilder>>mutate:to:' so that also these strange 
> obsolete subclasses are included, but it seems to me that
> it would be better to tackle the *real* problem, which
> is the fact that these obsolete classes are stored in
> such a messy (inconsistent) way.

Hey, the "real" problem is that we don't know how they got there ;-)

Cheers,
  - Andreas