RE: Outstanding 3.4 bugs?

Hi Ned,

> These bugs (and more, like the much-discussed bug with adding an 
> instVar to ClassDescription) still exist in 3.4g.

Here's an update on this problem. I could trace it down to a very obscure
breakage of the superclass/subclass invariant which can only happen when you
recompile any of the essential behaviors (Behavior, ClassDescription,
Class).

The short version of it is that ClassBuilder assumes it can see all the
subclasses of some class (this is obviously required since if it doesn't
then things will break horribly as instances of some classes are being
reshaped and others aren't). [*] However, during the "main mutation process"
ClassBuilder removes the class to reshape from its (old) superclass and
later puts back under the new superclass. So far so good.

Except that when we recompile the meta classes, we actually use the
non-metaclass hierarchy for determining the subclasses of some metaclass
(e.g., the subclasses of meta class "Foo class" are the meta classes of
Foo's subclasses "Foo subclasses collect:[:each| each class]"). 

This leads to an "interesting" effect when we recompile any of the
aforementioned behaviors. When we recompile (for example) ClassDescription
we recompile all the subclasses of Class (the meta class hierarchy) as well.
However, at the time when we recompile "Behavior class" we don't see
"ClassDescription class" as one of its subclasses - because while
recompiling we have removed ClassDescription from its superclass (Behavior).
Duh...

So I actually tried to simply "remove the removal" but apparently that's not
quite enough. I haven't had the time to go beyound this but it is clear that
the problem we are seeing is an (accidental) breaking of the
superclass/subclass invariant (when you look at the errors real close you
can see that it is caused by a meta class which wasn't reshaped).

[*] Because of the importance of the superclass/subclass invariant I
actually think that #addSubclass: and #removeSubclass: should really be
private messages. To me these look "just like the others" but using those
without knowing what you do means you're going to break the system a _long_
time after you did it. Similarly with "Class new" or any of these messages -
they ought to be screened and either raise errors or do something sensible.

So at this point it is clear what is causing the problem and at least what
part of the solution must be - namely _strict_ adherence to the
superclass/subclass invariant.

BTW, forget about everything I wrote in that other message. It's plain
nonsense. This happens to me all the time when I start to think "meta" and
get myself messed up with "an instance being the class of its class". That
all works perfectly well as it should.

Cheers,
  - Andreas