Pharo Smalltalk-實例化對象后，是否可以將super分配給其他實例？

Question

假設我們有一個oneInstance和secondInstance ， SomeClass和一個OtherClass之一，下面是示例類層次結構：

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

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

是否可以在運行時更改oneInstance，以便它的“超級”消息發送到達secondInstance。

oneInstance和secondInstance 合並本質上使oneInstance就像它們是一個對象一樣工作，並且該結構看起來好像是從諸如以下這樣的實例化的：

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

最簡單的是如果我可以在一個super := secondInstance上分配super := secondInstance ，然后再將其改回:D

PS。 本質上，我們通過使secondInstance為“ super”來對其進行重分類，因為它們現在是一個具有兩個狀態的對象，假定oneInstance是從Object繼承而來的，而沒有其他狀態，而是它自己的。 多數情況下，利用繼承鏈的默認方法查找對我有利。 我能找到的最接近的東西是對象切片https://en.wikipedia.org/wiki/Object_slicing

另一種查看方式是：

secondInstance正在接收消息，它是OtherClass的一個實例，一切都很好。 它接收到的某些消息不在OtherClass中，因此方法查找沿繼承鏈上升到SomethingClass，然后到達Object，ProtoObject等，最后應將它們轉發到另一個實例。 這個過程應該是完全透明的。

Answer 1

首先，在Pharo和Squeak（以及大多數Smalltalks）中，您總是在運行時。 顯然，如果有可能做某事，就可以在“運行時”做某事。 :)

通常，搞亂“常規代碼”的元功能會導致欺騙性很強的代碼，無論是對您還是其他人，都很難調試。 因此，除非確實需要執行這些操作，否則實現#doesNotUnderstand：並使用#respondsTo：等通常是“不良樣式”。

透明轉發器對象的一個​​明顯示例是OODBS的代理-但實際上並沒有很多好的示例。

但是要更精確地回答-在您實現#doesNotUnderstand的過程中：-僅查詢self respondsTo: aMessage selector （或類似的self respondsTo: aMessage selector ），然后根據該決定來決定是否委托。