MasterZivВыбор реализации метода по типу не только первого аргумента метода (this), но и всех остальных тоже.Интересная идея.
А насколько часто нужен такой функционал? Т.е. когда типы параметров явно отличаются, мы делаем перегрузку функций, то тут всё ок. Остаются случаи, когда типы параметров находятся в иерархии классов. Но тут мы тоже можем явно написать функцию для каждого случая. В любом случае нам придётся писать такую функцию. Поэтому не совсем понятно, какая реализация диспетчеризации планировалась? В случае с this ответственность лежит на классе this, а что будет в случае остальных параметров?

MasterZivты не сможешь написать тут функцию.тогда я, наверно, не совсем понял суть требуемой доработки.
Можно какой-нибудь пример для демонстрации?

MasterZiv, как по мне, так слегка сомнительная концепция: один класс принимает решение о выборе метода на основе виртуальной таблицы объекта другого класса.
И таки это можно реализовать, вызывая внутри метода класса методы объектов и выполняя нужный функционал там. Будет выглядеть запутанно, да, но реализовать можно. Второй вариант: определение типа параметров перед вызовом метода + перегрузка(там же в вики пример на с++).
Ну и всё-таки я не могу придумать, где оно может понадобиться.

MasterZivКто тебе сказал, что это делает ОДИН КЛАСС ?В коде одного класса.MasterZivТам же дан пример о столкновении двух объектов при моделировании...пример не показательный, так как столкновение нормально делается по-другому(собственно, оно там и так сделано по-другому, но как эмуляция реализации идеи), и там множественная диспетчеризация не требуется.

Давайте ещё раз. Простой пример: есть класс X, с методом, принимающим параметр класса А. Класс А является корнем иерархии классов. Идея MD: мы пишем X::m(A a), X::m(B a), X::m(C a),... и внутри пишем реализацию на каждый класс иерархии. При выполнении рантайм понимает, что у нас за объект и вызывает соответствующий метод. Сейчас будет вызван метод X::m(A) всегда.

В примерах реализация делается за счёт определения класса через dynamic_cast внутри метода X::m.

У меня есть 2 замечания к самой идее: 1. Реализация класса X зависит от иерархии классов A. Это неправильно: в случае добавления класса в иерархию, возможно нужно будет править код в X, добавлять ещё один метод m.
К слову сказать, у меня есть работающий код "столкновения" двух объектов, в котором параметры столкновения передаются методу обработки классу самого объекта. Это "один" метод на все типы объектов, т.е. тут стандартная диспетчеризация
2. Класс X принимает решение об обработке в методе m на основе класса входящего параметра. Это допускается, но сомнительно.

Ну и, всё ещё не могу придумать пример.

MasterZivА зачем вообще компьютер, он же дорогой такой... Лучше на счетах считать!Всё упирается в востребованность. Компьютеры востребованы, счёты - нет. И есть куча примеров, где компьютеры справляются лучше, чем счёты. Но всё ещё нету примеров, где MD справляется лучше, чем то, что есть сейчас. Где примеры?
MasterZivеще раз, с чего ты взял, что то, какой метод будет вызван - это реализация класса X, а не языка C++ ?да, верно, это реализация С++. Но по первому замечанию я не согласен, т.е. это не в плане реализации MD, а в плане архитектуры приложения: в случае изменения иерархии классов А, нам (вероятно) надо менять код класса X. Когда мы работаем с объектами иерархии А через интерфейс, нам менять X не нужно.

MasterZivНемного почитал статью про open multimethods.там, оказывается, всё сложнее, чем я себе представлял.MasterZivПоэтому все твои опасения напасны, это не будет реализацией какого-то класса.да я не опасался, я просто думал, что если делать через метод, то архитектура будет не шибко иделальнойMasterZivТакже там есть в самом начале примеры того, где OMM могла бы быть полезной, приводится пример системы кодирования изображения с подсистемой перекодирования изображения из одного формата в другой.о, так под это подходят любые конверторы из чего-то во что-то. А так же какие-нибудь агрегаторы. Ну всё, можно делать!

MasterZiv, а так же любой бинарный оператор...

ёпрст... как мы сейчас выживаем вообще без MD!?!

boobyЗавели себе козу статической типизации с выдумыванием обрядов моления на неенет ничего плохого в статической типизации :) Почему все обязательно становятся адептами или той или иной типизации? С++ хорош тем, что можно выбрать и настроить в нужном месте кода нужную типизацию. Или ненужную. И всё равно это будет работать!maytonПросто ООП себя исчерпало.а какие есть альтернативы? Концептуальные? Причём, чтобы можно было решать те же задачи, что решались с помощью ООП. Чем заменить ООП?