On 8 January 2014 15:38, Tobias Pape <Das.Linux at gmx.de> wrote:
>
> On 08.01.2014, at 16:34, Chris Muller <asqueaker at gmail.com> wrote:
>
>>>> A new version of Kernel was added to project The Inbox:
>>>> http://source.squeak.org/inbox/Kernel-cmm.830.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: Kernel-cmm.830
>>>> Author: cmm
>>>> Time: 7 January 2014, 9:31:35.206 pm
>>>> UUID: 43453587-ee4b-48e4-93ec-43983f0c82ed
>>>> Ancestors: Kernel-fbs.829
>>>>
>>>> Removing a class should remove its subclasses too.
>>>>
>>>
>>> No.
>>
>> Why?
>>
>>> See comment
>>
>> Ok, so if I remove the comment we're golden..?
>>
>> Otherwise, I want to understand why I would ever want to have a class
>> with an ObsoleteSuperclass..?
>>
>> Because I think the system should cater to regular Smalltalk
>> development.  "Regular" meaning, all classes have a valid superclass.
>
> Ok, let me rephrase:
> I fear that there is functionality in the system that depends on
> being-removed classes not removing their subclasses.
> However, I am not sure.
>
> Can one of the older (in the sense of wiser) guys chime in here?

I'm not older or wiser, but if we remove subclasses when we remove
classes, unloading an MCClassDefinition will result in a bunch of
MCClassDefinition's backing classes disappearing out from under them.
As a package unloads, each subclass will be #unload'd N times, N being
its depth in the inheritance hierarchy (where the root's the argument
to the method).

That's why while I'm happy with the _feature_, I want to see it as a
_new_ feature, leaving #removeFromSystem: removing just a single
class.

frank

> If we know this cannot happen, I’m fine with the change.
>
> Best
>         -Tobias
>
>
>
>