Delphi для .NET реализовал в языке Delphi понятие переменных класса (которые могут содержать ссылку на тип класса), методов виртуального класса и виртуальных конструкторов (вызываемых через ссылку на класс). Ни один из них не имеет прямого аналога в CLR - статические методы в CLR не могут быть виртуальными, а конструкторы не могут быть виртуальными.
Поскольку CLR обладает таким богатым набором информации о типах среды выполнения, эти артефакты не являются строго необходимыми в CLR. Если вы хотите создать экземпляр типа во время выполнения в коде, который не знает точный тип во время компиляции, вы можете сделать это с помощью отражения или других методов. Эти особенности языка Delphi выросли из изначально скомпилированного продукта Win32, где информация о типах среды выполнения ограничена. Все это было реализовано в .NET 1.0 и 1.1 задолго до появления чего-то подобного DLR.
Эти возможности языка Delphi можно эмулировать в CLR с использованием отражения, но по соображениям производительности мы решили реализовать их непосредственно в IL, создав тип «метакласса», который являлся дополнительным элементом для каждого типа класса, объявленного в Delphi. Если Delphi-код назначил тип Delphi-класса для ссылочной переменной класса, мы сгенерировали IL-код, чтобы присвоить переменной экземпляр одиночного экземпляра соответствующего мета-класса. Вызовы виртуальных методов через ссылочную переменную класса были сгенерированы как вызовы виртуальных методов IL для экземпляра мета-класса, который отскочил от фактической реализации статического метода в соответствующем типе класса. Это позволило вызовам виртуальных методов класса по-прежнему вести себя полиморфно (вызывать реализацию, соответствующую типу экземпляра, используемого для вызова) и с минимальными затратами времени выполнения. Эта реализация также была безопасной для типов и проверяемой.
Эти функции метода виртуального класса были применимы только к классам, объявленным в синтаксисе Delphi, и применимы только в синтаксисе Delphi. Я считаю, что мета-типы были помечены как несовместимые с CLS, так что другие языки .NET будут (наиболее вероятно) игнорировать их при использовании классов, созданных в Delphi. Другие языки .NET не могли использовать эти специфические языковые возможности Delphi (если разработчик не был действительно определен и прошел через леса, чтобы сделать соответствующие вызовы к / через уродливые мета-классы)
Как правило, не следует ожидать, что другие языки будут использовать не-CLS-артефакты, созданные / для вашего языка. Если вы хотите, чтобы другие языки использовали материал, созданный на вашем языке, вам необходимо выяснить, как представить свой особый соус таким образом, чтобы его можно было представить в разумной форме в терминах, соответствующих CLS. Это может быть невозможно в зависимости от природы специального соуса.
Методы виртуального класса Delphi были доступны для других языков .NET как обычные статические методы. Полиморфная природа не была открыта для других языков .NET в значительной степени потому, что CLS (или другие языки) просто не могут выразить это понятие.
В идеале, каждый язык мог бы одинаково хорошо выражать все мыслимые конструкции. Но на самом деле это не так. Некоторые графические функции легче выразить в декартовых координатах, в то время как другие значительно упрощаются благодаря использованию полярных координат. То же самое верно для языков программирования.
Можно изобретать новые средства выражения на вашем родном языке, даже если они реализованы в CLR. Просто убедитесь, что у программистов, работающих за пределами вашего языка, четкое определение того, как выглядят ваши типы, если вы ожидаете, что код вашего языка будет вызываться другими. Ваша реализация будет иметь двойственность: как вещи выглядят для пользователей вашего языка, и как вещи выглядят для пользователей за пределами вашего языка.
Сноска. Я не верю, что что-либо из этого относится к новому продукту Delphi для .NET, Delphi Prism. Я не думаю, что Delphi Prism поддерживает методы виртуальных классов.