Pharo Smalltalk - Is it possible to assign super to some other instance after the Object has been instantiated?

Question

Suppose we have oneInstance and secondInstance , one of SomeClass and one OtherClass with the example Class hierarchy below:

oneInstance
Object
 - SomeClass (some variables of it's own, nothing major)

secondInstance
Object
 - SomethingClass
 - OtherClass (just about any class in the tree here)

Is it possible, at runtime, to change oneInstance so that it's "super" message sends reach secondInstance.

oneInstance and secondInstance merge essentially making oneInstance work as if they are one object and the structure appear as if they were instantiated from something like and:

secondInstance wraps around oneInstance
    Object
     - SomethingClass
     - OtherClass (just about any class in the tree here)
     - SomeClass (some variables of it's own, nothing major)

The simplest would be if I could assign super := secondInstance on oneInstance for a bit and then change it back :D

PS. Essentially we are reclassing oneInstance by having secondInstance as it's "super" they are now one object with the state of both presuming oneInstance is subclassed from Object with no other state but it's own. Mostly a hack to use the inheritance chain's default method lookup to my advantage. Closest thing I could find is Object Slicing https://en.wikipedia.org/wiki/Object_slicing

Another way to look at it would be this:

secondInstance is receiving messages, it's an instance of OtherClass, all is well. Some of the messages it receives are not in OtherClass so method lookup goes up the inheritance chain to SomethingClass and then to Object, ProtoObject, etc. and finally they should be forwarded to the other instance. This process should be entirely transparent.

Answer 1

First of all, in Pharo and Squeak (and most Smalltalks) you are always at runtime. So obviously, if its possible to do something, its possible to do it at "runtime". :)

Generally messing around with meta capabilities for "regular code" leads to really deceptive code that is hard to debug, both for you and especially others. So to implement #doesNotUnderstand: and using #respondsTo: etc, is normally "bad style" unless you REALLY have to do these things.

An obvious example for transparent forwarder objects is proxies for OODBS - but there really aren't many good examples.

But to answer more precisely - in your implementation of #doesNotUnderstand: - just query if self respondsTo: aMessage selector (or similar) and make your decision to delegate or not based on that.