Dan Ingalls wrote:
> 
> Folks -
> 
> Scott Wallace just ran into a nasty bug because of how we create root classes, and I want to prevent it from happening again.  In Squeak we create root classes with the pattern
> 
>         nil subclass: #RootClassName ...
> 
> While this has a certain uniformity with the way we create other classes, it allows a serious error to pass undiagnosed.  In Scott's case he read a fileOut into a system in which the superclass of one of the new classes was not defined.  "No problem" said the fileIn code, we'll just put it in undeclared and give you a nil.  This is usually fine, but in this case a VERY different thing happens if you run with nil.  In Scott's case, every time an instance of that class got created, it crashed his system with recursive messageNotUnderstood.  Even for a Jedi, this can be a very difficult problem to track down.  What makes it so bad is that the current pattern allows it to happen very easily.
> 
> Fortunately, it's not a hard problem to aviod.  For instance we could simply change this pattern to
> 
>         Class rootClass: #RootClassName ...
> 
> With this change, any future occurrences of this error would be diagnosed on the spot and in an understandable fashion.
> 
>  The question I have is, how do other Smalltalks do this?  Is there an ANSI standard way of doing it?  I'm open to other approaches, but I know the status quo is unacceptable.
> 
> Thanks in advance
> 
>         - Dan

In VisualWorks 3.x all that is required is that #doesNotUnderstand: be defined in the
newly created class.  Interestingly enough, this contains references to
an expression such as "Object somesortofErrorSignal", and this will work even in cases
where Object itself is not defined ( because nil has the same signals defined- so I
think the VW guys ran right into the same problem at some point ).

On a broader note- scan through the progress descriptions I've been posting for Oasis
and I think you would notice that there are other issues to address.  Oasis currently
handles arbitrarily complete ( or incomplete ) chunks of code quite easily, no matter
what order the various bits are in.  In the above example, Oasis would have created the
proper class ( if a name had been specified ) and could even have provided that class
with any instance variables referenced in the subclasses defined in the filein ( although
the algorithm I used for that was a bit naive, so I'll be coming back to that issue
in the future ).  Otherwise, if nil had been specified then it would have done that,
and VisualWork's normal mechanism for copying #doesNotUnderstand: to the newly minted class
would have covered it.

- les