On 8 January 2014 16:29, Chris Muller <asqueaker at gmail.com> wrote:
> 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).

So I should really check ALL my mail before responding.

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

It won't route through SystemDictionary because there are no instances
of SystemDictionary in the base image. But yes, Environment >>
#removeClassNamed: does guard.

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

That doesn't make me any happier :) OK, so in my other mail my worry
of multiple #unload sends won't come to pass, but the N lookups for
the _usual_ code path just smells bad. I don't see why we shouldn't
keep just-this-class as the default behaviour - it's really quite deep
in the bowels of the system - and keep yours & Colin's unload-em-all
as a _user level_ optimisation. It's great for the _user_ to be able
to do this.

> 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).

Yeah, as I said I would much rather see it the other way round.

frank