Причина WinRT для запрета пользовательских универсальных типов или интерфейсов

Question

Прочитав немного о WinRT здесь и из колод Build, может ли кто-то пролить свет на конкретное обоснование, которое заставляет их запретить нам проходить наш собственный IFoo , но они делают это для своих собственных утвержденных универсальных типов интерфейса?

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

Я не могу представить себе "сглаживание" некоторых из моего класса C #вспомогательные библиотеки не универсального типа, которые я в основном хочу использовать из C ++, а не столько из JS.

Я хочу, чтобы первоклассная поддержка Intellisense и API была такой же, как и для ваших собственных типов MS.

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

Спасибо.

Answer 1

Под крышками типы, которые проецируются как IXxx, реализуются так называемыми «параметризованными интерфейсами» или «интерфейсами».Каждая языковая проекция знает, как выразить встроенные параметризованные интерфейсы естественным и знакомым способом - например, параметризованный интерфейс IMap проецируется CLR как IDictionary.

Языковые проекции (особенно JS) не 'не знаю, что делать с настраиваемыми параметризованными интерфейсами, поэтому они не допускаются.

Нет способа узнать, будет ли это ограничение ослаблено в будущем, потому что нет способа узнать, какие функции будут добавленыв Windows в будущем.

Answer 2

Также для сборки компонента есть 2 преимущества:

• расширение по составу - лучшая модель для компонентов (помните, что вы все равно можете использовать интерфейсы для тестирования (например, C # lib), которые они просто не могутбыть выставленным как экспортируемые компоненты WinRT

• Никаких полиморфных вызовов через границу COM-вызовов, поскольку производительность не может быть встроенной будет плохой

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