Скорее не виртуальные функции, а делегаты (новое модное слово)

Давай теперь я расскажу, что я думаю о текущей концепции ХиАсм.
Можно рассмотреть эту концепцию с разных точек зрения.

Итак. С точки зрения построения программы.

Есть две сущности: процедуры и функции. И то, и другое, можно либо использовать, либо реализовывать.
Комбинация всего этого даёт нам как раз четыре возможные точки:
реализация процедуры (левая)
реализация функции (нижняя)
использование процедуры (правая)
использование фукции (верхняя)

Данные две сущности можно рассматривать и как inline-подстановку, тогда это будет часть кода и часть выражения, выполняемые в контексте компонента, в котором они реализованы.

Теперь с точки зрения данных.

Есть две сущности: клиент и сервер. А есть два направления данных: передача и приём.
Комбинация всего этого даёт нам опять четыре возможные точки.

НО! Данные могут быть не просто числом или строкой, а (если рассматривать ещё и с точки зрения ООП) могут являться ссылкой на объект. А если точнее, то нужно говорить об использовании и реализации интерфейса. И сейчас это скрыто внутри компонента (массивы, потоки) и не вписывается в концепцию ХиАсм (нельзя при помощи компонент сделать свой интерфейс, передать его как данные, сохранить его в переменной, использовать его). Handle мультика пока нельзя в полной мере считать интерфейсом, поскольку без самого мультика это просто число.


Возможно, это могло бы решить проблему реализации и использования интерфейса, но как среда определит, на какой мультик ссылается этот Pointer? Ведь от этого должен зависеть набор точек у этого компонента. Предложение использовать ссылку на мультик уже несколько раз отвергалось. В конце-концов, один объект может предоставлять несколько интерфейсов, как быть в этом случае?