WinRT reason for disallowing custom generic types or interfaces

Question

After reading about WinRT a bit here and from Build decks, can someone shed light on the specific rationale that lead them to disallow us from passing our own IFoo, ye

Answer 1

Under the covers, the types which are projected as IXxx are implemented by what are called "parameterized interfaces" or "pinterfaces". Each language projection knows how to express the built-in parameterized interfaces in a natural and familiar fashion - for example, the IMap parameterized interface is projected by the CLR as IDictionary.

The language projections (especially JS) don't know what to do with custom parameterized interfaces, so they're not allowed.

There's no way of knowing if this restriction will be relaxed in the future, because there is no way of knowing what features will be added to Windows in the future.

Answer 2

Also for building component there are 2 advantages

• extension by composition is a better model for components ( remember you can still use interfaces for testing ( eg a C# lib) they just cant be exposes as WinRT exportable components

• No polymorphic calls across the COM call boundary since cant be inlined performance will be poor

I'm not sure JS would have limited this since JS cant create objects anyway only consume they could have added another JS limitation - not framework interfaces are supported..