[Cuis-dev] Behavior of #superclass: message

Martin McClure martin at hand2mouse.com
Thu Nov 27 14:02:27 PST 2025


It's good to see you diving into these aspects of the system -- that's 
how you learn, and it's well worth learning.

Changing the superclass is, as the comment hints, in general a dangerous 
operation. If you just assign a new value to the superclass instance 
variable in the class and metaclass, that changes the class hierarchy. 
But the new superclass might declare different instance variables and/or 
class instance variables. So now instances may not have the right 
instance variables, or even the right number of instance variables. 
Depending on the implementation of the VM, this could crash the system. 
It will at least lead to incorrect behavior.

The safe way to change the hierarchy tends to go something like:

*  Make a copy of the class and metaclass whose superclass is changing.

* Compile all the methods defined by the class and metaclass on the 
copied classes so that instance variable offsets are correct.

* Find all the instances of the class and metaclass. For each, create an 
instance of the new class or metaclass, and copy the common instvars 
over. Then send #become: to replace the old instance with the new one.

* Then repeat all of the above for any subclasses of the class whose 
superclass changed.

Development tools tend to do all of that for you transparently, but 
don't let that fool you into thinking it's simple.

Regards,

-Martin

On 11/27/25 1:47 PM, Facundo Javier Gelatti wrote:
> That makes a lot of sense. Maybe the meaning of the message is just 
> that: to change the superclass of the receiver and nothing else.
> In that case, maybe I can add something to the method comment, to 
> avoid the confusion I had.
>
> On the other hand, about the implementation possibilities (supposing 
> we wanted to implement it so that it did change the metaclass 
> hierarchy), the #superclass: message is currently implemented on 
> Behavior and overridden in Class. As the metaclasses include behavior 
> from Metaclass and Behavior but not from Class, then we could add this 
> at the end of the method Class>>#superclass::
> self class superclass: self superclass class
> and that makes my example work as I originally expected.
> I find it interesting because encapsulation is preserved while using a 
> single message (with two different methods).
>
> Thanks Martin for your prompt and clear response!
> Cheers,
> Facu
>
> El jue, 27 de nov de 2025, 18:15, Martin McClure 
> <martin at hand2mouse.com> escribió:
>
>     Hi Facu,
>
>     I haven't looked at the code, but perhaps #superclass: is a
>     low-level method that just does that one change.
>
>     A higher-level facility might want to change the superclass in
>     both the class and the metaclass, but it can't do that in one
>     method because of encapsulation -- one method can't change the
>     superclass instance variable in two different objects. So what
>     message would it send to each of the class and the superclass? One
>     logical selector to choose for that would be #superclass:.
>
>     Regards,
>
>     -Martin
>
>     On 11/27/25 12:42 PM, Facundo Javier Gelatti via Cuis-dev wrote:
>>     Hi!
>>
>>     I've noticed that the #superclass: message does not affect the
>>     superclass of the (meta)class of the receiver. For example:
>>
>>     Object subclass: #A instanceVariableNames: '' classVariableNames:
>>     '' poolDictionaries: ''.
>>     Object subclass: #B instanceVariableNames: '' classVariableNames:
>>     '' poolDictionaries: ''.
>>
>>     B superclass. " => Object "
>>     B class superclass. " => Object class "
>>
>>     B superclass: A.
>>
>>     B superclass. " => A "
>>     B class superclass. " => Object class (not A class)"
>>
>>     The Class>>#superclass: method has a comment that says "Not to be
>>     used lightly!", so I'm not sure if this is in fact the expected
>>     behavior (but at least I was surprised by it).
>>
>>     Cheers!
>>     Facu
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20251127/daa0a1fd/attachment.htm>


More information about the Cuis-dev mailing list