[Cuis-dev] nil subclasses (Re: clever or silly idea?)

[Andres Valloud]

Thanks!

On 6/13/24 8:04 AM, Juan Vuletich via Cuis-dev wrote:
> On 6/12/2024 1:06 PM, Andres Valloud via Cuis-dev wrote:
>> Hi,
>>
>>> 3. This is another issue. If you see the definition of ProtoObject in
>>> the browser, or the comment at UndefinedObject >> 
>>> #subclass:instanceVariableNames:classVariableNames:poolDictionaries:category:
>>> , the recommended way to create the class is to make it subclass of
>>> Undefined object, and then do `Parrot superclass: nil`. This is
>>> disturbing.
>>
>> Agreed.
>>
>>> Parrot will have superclass == nil, but will be included
>>> in the subclasses array of ProtoObject. The superclass / subclass
>>> invariant is broken. This code has been there for 25 years, and I
>>> wouldn't modify it lightly. Moreover, if you evaluate the suggested
>>> class definition, it will appear repeated times, like ProtoObject
>>> subclasses = #(Object MessageCatcher BreakingMethodWrapper Parrot
>>> Parrot Parrot Parrot) . So something has to be done.
>>
>> Oof, what a mess.  Strange, I do not remember this behavior from 
>> Squeak back in the early 2000s, and I am sure I was creating 
>> subclasses of nil at the time.  Maybe it's been too long.
> 
> Just pushed a fix for this.
> 
>>
>>> I guess the only subclass of nil created in 25 years is ProtoObject 
>>> itself...
>> Well, if you get silly behavior like what you describe, that sure acts 
>> as a disincentive :).
>>
>> Andres.
> 
>