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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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