[BUG?] MC creates mock classes but doesn't quite destory them

Daniel Vainsencher danielv at netvision.net.il
Sun Sep 14 14:42:49 UTC 2003


I did a little exploration - as you say Class>>removeFromSystem is the
right method to call, because it does all the cleanup, including
obsolete, which removes the reference to the class in its superclass
subclasses collection.

I think SystemDictionary>>removeClassFromSystem:logged: should probably
be renamed something more specific and obviously partial, like
removeBindingForClass:logged:

I now also seem to remember Roel working on this in ESUG, but don't see
this change on the KCP page. Roel, am I imagining things? 

Daniel

"David T. Lewis" <lewis at mail.msen.com> wrote:
> On Sun, Sep 14, 2003 at 12:06:31AM +0300, Daniel Vainsencher wrote:
> > I wouldn't be surprised if this is a bug in a system call to remove
> > classes, because a friend of mine seems to be seeing a symptom like that
> > in loading the Chronology package. Would be a worthwhile bug to catch if
> > that is so.
> 
> In the case of the Chronology package, the problem arises after calling
> SystemDictionary>>removeClassFromSystem:logged:. This method removes a
> class from the system dictionary, but allows the class to remain in the
> class hierarchy as a subclass of whatever it was originally subclassed
> from, which leads to browsers getting badly confused.
> 
> This may be just a documentation error, as the method comment says
> that the class will be removed from the "system", which a casual reader
> might assume means that it's removed from the image, and not just from
> the system dictionary. Presumably the right thing to do is to use
> Class>>removeFromSystem. If so, some better method comments may be all
> that is needed.
> 
> Dave



More information about the Squeak-dev mailing list