Интересно, где-нибудь такая возможность реализована?

Конечно, речь идет не о том, что меняется любой класс на любой другой класс (это бессмысленно). Но продвигать объект вверх по иерархии наследования, возможно имеет смысл. Например был объект класса заказ, стал отгрузкой. (если класса отгрузка родительский для заказа.). Все связи с этим объектом сохраняются, но он входит в подкласс и может использоваться по новому.

ps.
Ну или был квадрат - стал прямоугольником

Зачем это нужно.

Тут наверно издалека надо начинать,что бы контекст вопроса стал понятен.

Контекст заключается в том, что у меня есть система, где класс является множеством объектов в прямом смысле этого выражения. То есть я могу обратившись к классу, получить доступ к конкретному объекту (в т.ч. получить ссылку на объект) по каким-то атрибутам.

В этом контексте операция развития объекта (назовем ее так) приобретает тот смысл, что объект явно включается в подкласс. Совсем конкретный пример - переход от заказа к отгрузке... или что то типа того. Заказ - он как был так и остается. Если он входил в какие-то группы, он там так и есть. если на него были ссылки - их трогать не надо. интерфейс объекта не меняется. Но после "развития" это же заказ можно использовать как объект класса отгрузка. на него могут ссылаться как на отгрузку, он может входит в другие списки (куда могут входить отгрузки) и т.д.

Смысл операции КМК слово "развитие" очень хорошо передает.

С учетом того, что возможно множественное наследование, такая операция становится еще более интересной. Например класс отгрузка наследует помимо заказа еще и класс запись в фин книге. Получается, что при развитии объекта заказ в сторону отгрузки этот объект становится еще и объектом класса запись в фин книге. А это - уже совсем сбоку класс. То есть, с множественным наследованием, операция "развитие объекта" работает уже не только вверх по иерархии, но и во все стороны, которые в этой иерархии участвуют.

Вот эта картинка - она к чему? что на значит?
И какое отношение человеческие ноги к наследованию?

Самое главное - я не собираюсь спорить о смыслах и об абсурдности. Кому то не нравится множественное наследование, а кто-то наоборот уверен, что только оно имеет смысл. Я задал конкретный вопрос про конкретную операцию, которую можно сделать. а какой смысл в нее будут вкладывать - их дело.

rfgвносить в разные списки, а для этого никакой класс менять не надо
главный список - это сам класс. объект там есть по умолчанию.
класс - это множесто объектов.

что такое алкастинг?

но если я правильно понял - то ни капли не алкастинг.

думаю причина вопросов в том, что мало где реализована простая идея "класс - это множестов объектов". класс используют как фабрику объектов, но что бы организовать множество вводят всякие коллекции, экстенты и тд.

То есть для класса существует операция NEW имя_класса(парарметры_конструктора) ,что подразумевает создание нового объекта, но нет операции GET имя_класса (параметры_отбора_объекта) , что подразумевает получение ссылки на уже существующий объект. В существующих системах единственны способ сохранить доступ к объекту - сохранить ссылку на него (в эктенте, коллекции или как то еще). Как только ссылка потеряна - доступа к объекту утерян тоже.

Мой исходный вопрос интересен в контексте системы где такая операция GET есть. Объясню почему. Она позволяет ввести существующий объект в новый класс, а потом получить ссылку на него уже как на объект нового класса. Это подразумевает статический контроль типов. И это абсолютно не то,что мы можем обращаться к объекту класса-наследника по интерфейсу предка.

2 VipRos
да не показал ты ничего. я тебе таких скринов в экселе нарисую десять за час. Ты хоть раз где-нибуть связно мне объяснил, о чем ты говоришь? ссылку дал на доки, на описание или еще на что? Нет.
поэтому я тебя воспринимаю сугубо как тролля, извини. ну ладно... пусть будет тролль с понятиями. в смысле - термины знаешь.

2 mayton
Ржать конечно легче чем думать. Но, уважаемый, я, задав Вам вопрос об алкастинге, как-то сразу перешел на статический контроль типов. То есть, подумавши, можно сделать вывод что речь идет не об одном и том же.... ну, если вы понимаете что такое тип и его статический контроль, ибо all casting это механизм сильно динамический и затратный.

да, неправильно прочитал :) и тоже удивился, но потом подумал что может быть имеется в виду идея отработки всех входящих сообщений. типа как в смоллтоке. ну и ляпнул.

в общем -это не об апкастинге. Апкастинг - это вроде про ссылки. А я спрашиваю об операции, когда сам объект(инстанс) меняет свой класс в сторону наследника. Безотносительно к тому, есть на него ссылки или нет. Ссылки то как раз могут вообще не меняться, но при обращении по этим ссылкам будут вызываться новые реализации методов (без всяких приводящих выражений и модификаторов) .

2VipRos спасибо.
давай я уточню, что. спрашиваю про языковую команду
например
это что бы преобразовать некоторые объекты класса class в объекты класса-наследника subclass

коллекция то зачем?

да, опция.

Любую проблему можно как то решить. Вопрос в легкости и очевидноости решения.

Зачем нужно. Книжный (вроде бы) пример - класс сотрудники и производный класс начальники . . Существует сотрудник, который ходит в столовую , посещает долговременный тренинг и т.п. В общем на соответсвующий объект из других частей системы (в том числе из списков столовой и тренинта) есть ссылки. И вдруг сотрудник стал начальником. Как нам это развитие сотрудника в начальники изобразить в системе, оставляя все ссылки на объект нетронутыми? Я могу такую операцию сделать в лоб, а тут, собственно, аккуратно интересуюсь, насколько это народу интересно. Но в очередной раз натыкаюсь на то, непонимание существующее меджу программистами и СУБДшниками. В частности в том, что первые не понимают, как может быть объект без ссылки.

Язык по верхам здесь . Английская версия на ODBMS.ORG
Технология(формально) здесь .
Презентация здесь .

Это был книжный пример. В смысле - я не говорю. что так надо делать. Я говорю, что так можно сделать.