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

Daniel Vainsencher danielv at netvision.net.il
Sun Sep 14 17:00:34 UTC 2003


Yes, I looked, and Roels change is for a rename method which is
similarly split, not for removal. So I propose:
removeClassFromSystem:logged: -> removeBindingForClass:logged:

Any objections alternatives? if not, I'll send in a changeset.

Daniel

ducasse <ducasse at iam.unibe.ch> wrote:
> es roel was cleaning this part but now he is back in belgium and will 
> be swamped for
> some weeks.
> Roel could you send your changes. Daniel I was thinking that roel sent 
> a test and fix while he was at ESUG.
> May be you should check that.
> 
> Stef
> 
> 
> >
> > 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