[squeak-dev] The Inbox: Kernel-cmm.830.mcz

Chris Muller asqueaker at gmail.com
Wed Jan 8 16:29:43 UTC 2014


On Wed, Jan 8, 2014 at 9:45 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
> 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).

Browse MCClassDefinition>>#unload and trace it into
SystemDictionary>>#removeClassNamed:.  There's a guard to ensure it's
still there before trying to unload it.

So it's just N lookups in a Dictionary, it won't be unloaded N times.

Nevertheless, I factored the individual remove as
#primRemoveFromSystem:, just for you.  :)  So if some external caller
wants to use that they can (although doing it seems it leaves the
system in a bad state, maybe there's some use case I'm missing).


More information about the Squeak-dev mailing list