Pharo Smalltalk - Можно ли присвоить супер другому экземпляру после того, как объект был создан?

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 на oneInstance для бит, а затем изменить его обратно :D

PS. По сути, мы переклассифицируем oneInstance, получив secondInstance, поскольку это «супер», теперь они представляют собой один объект с состоянием обоих предполагающих, что oneInstance подклассифицирован из Object без какого-либо другого состояния, но он является собственным. В основном взломать метод поиска по умолчанию наследования по умолчанию в моих интересах. Ближайший вещь, которую я смог найти объект Строгание https://en.wikipedia.org/wiki/Object_slicing

Другой способ смотреть на это было бы так:

secondInstance получает сообщения, это экземпляр OtherClass, все хорошо. Некоторые сообщения, которые он получает, не находятся в OtherClass, поэтому поиск метода переходит к цепочке наследования SomethingClass, а затем к Object, ProtoObject и т. Д., И, наконец, они должны быть перенаправлены в другой экземпляр. Этот процесс должен быть полностью прозрачным.

Answer 1

Прежде всего, в Pharo и Squeak (и большинстве Smalltalks) вы всегда во время выполнения. Так что, очевидно, если его можно что-то сделать, его можно сделать в «runtime». :)

Вообще беспорядок с мета-возможностями для «обычного кода» приводит к действительно обманчивому коду, который трудно отлаживать, как для вас, так и для других. Таким образом, для реализации #doesNotUnderstand: и с использованием #respondsTo: и т. Д., Как правило, «плохой стиль», если только вы ДЕЙСТВИТЕЛЬНО должны делать это.

Очевидным примером для прозрачных объектов экспедитора являются прокси-серверы для OODBS, но примеров действительно мало.

Но для более точного ответа - при выполнении #doesNotUnderstand: - просто введите запрос, если self respondsTo: aMessage selector (или аналогичный) и принять решение о делегировании или нет на основе этого.