А как было хорошо и понятно было в Дельфи

2Сергей Губанов- спасибо за разъяснения механизма сообщений. Честно говоря, не сразу въехал... Видимо от того, что мой мозг не очень привык к использованию RTTI (грубо говоря, вообще никогда не использовал)

Ну перейдем к сравнению... Конечно же, я немного лукавил про сравнение: мне сразу было известно, что эффективнее, чем это сделано с использованиемprocedure of object- сделать нельзя. С уровнем доверия три девятки.
Ну значит так, на момент "использования" происходит примерно следующее:
1.procedure of objectв Дельфи
1.1. Накиданы аргументы в стек, в соответствии с сигнатурой типа
1.2. Кидаем в стек параметр self (он же this, смещение +4 в поле Event)
1.3. Делаем косвенный вызов по адресу, лежащему по смещению +0 в поле Event
1.4. Исполняем нужный нам код

2. Сообщенние в КП
2.1. Накиданы аргументы в поля сообщения. Будем считать их полностью соответствующими сигнатуре типа по п.1.1. И лежат эти поля тоже в стеке (локальная переменная типа Message)
2.2. Кидаем в стек адрес нашей переменной типа Message (VAR-переменная в HandleMessage)
2.3. Добываем из поля Event адрес объекта-получателя
2.4. Кидаем его в стек, как параметр self (он же this) для HandleMessage
2.5. Добываем из vmt этого объекта адрес метода HandleMessage, и делаем вызов этого метода. Одна операция косвенного вызова, видимо.
2.6. В методе HandleMessage первым делом добываем адрес дескриптора типа для принятого сообщения. Как точно - не знаю. Не думаю, что сложнее чем какое-то количество косвенных обращений в память. Подозреваю, что одно
2.7. Осуществляем WITH-селектирование по типу. Опять же, точного механизма не знаю. Но подозреваю, что для каждой ветки происходит вызов некой системной ф-ии, которая просматривает список предков полученного типа, и сравнивает его с нужным для данной ветки. В смысле, посложнее будет, чем банальный CASE
2.8. Исполняем нужный нам код. В соответствии с рекомендациейИльи, не напрягаться с лишними вызовами методов объекта. Впрочем, я и сам всегда считал логически правильным, возложить ответственность за inline однократно используемой процедуры - на компилятор
И что у нас получается? В смысле, на много ли хуже система сообщений в КП, чем практически идеальная по п.1...
На несколько (скажем - парочку) обращений в память, и плюс на, не очень понятную по эффективности, систему WITH-селектирования
Как говорится, не так уж и плохо - нет промежуточных функциональных вызовов, как в тупом применение патерна Command, что я показывал... Хотя, там не было селектирования...
Но что главное-то хотел я сказать: обойти по эффективности применениеprocedure of object- практически не реально

И представить, в связи с этим, на Ваше внимание некое "философское" обобщение:
Процедурный тип, при появлении ООП (в смысле - методов класса/типа) требует некой модификации. Ну или адаптации... И, думается - не вместо, а в дополнение.
И примеров таких "модификаций" я вижу два: как в C++ (там этот тип называется методы класса), и как в Дельфи (procedure of object). Ну а остальное Вы слышали, наверное - не сдержался я, и в других ветках проболтаться успел

И вот, в связи с вышесказанным, мне хотелось бы повторить для КП-сообщества стартовую фразу: "Никак пока в толк не возьму, отчего в КП нет такого полезного типа"
Думал-думал - ну ничему не противоречит вроде... Появляется и "защита" - работает как все указательные типы...

Что скажите коллеги
Мне так кажется, что:быстр, вынослив, и кормить не надо