Remove the TypeKey concept as the primary user for the concept is unable to use it effectively.#79418
Conversation
…ble to use it effectively.
jkoritzinsky
added
area-System.Runtime.InteropServices
source-generator
jkoritzinsky
requested review from
AaronRobinsonMSFT,
elinor-fung and
jtschuster
|
Tagging subscribers to this area: @dotnet/interop-contrib Issue DetailsPreviously, each of the interface types for the vtable stub generator was generic on a type However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the
|
|
Failures were #79874 |
| The user will be required to implement `IUnmanagedVirtualMethodTableProvider<T>` on the type that provides the method tables, and `IUnmanagedInterfaceType<T>` on the type that defines the unmanaged interface. The `T` types must match between the two interfaces. This mechanism is designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. | ||
| The user will be required to implement `IUnmanagedVirtualMethodTableProvider` on the type that provides the method tables, and `IUnmanagedInterfaceType<TUnmanagedInterfaceType>` on the type that defines the unmanaged interface. The `TUnmanagedInterfaceType` follows the same design principles as the generic math designs as somewhat of a "self" type to enable us to use the derived interface type in any additional APIs we add to support unmanaged-to-managed stubs. | ||
|
|
||
| Previously, each of these interface types were also generic on another type `T`. The `T` types were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for example `IID`s in COM, without interfering with each other or requiring using reflection-based types like `System.Type`. However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the `IUnmanagedVirtualMethodTableProvider<T>` implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from the `System.Type` instance without causing additional problems. |
There was a problem hiding this comment.
nit for the next update to this file: the 'previously' is a bit odd without a reference point (since there isn't a previous public API). Maybe a subsection like 'Alternative design considered/rejected'?
There was a problem hiding this comment.
I'll make sure to add that when I add the additional revisions based on the further API design iterations we're doing.
…ble to use it effectively. (dotnet#79418)
ghost
locked as resolved and limited conversation to collaborators
4 participants
Previously, each of the interface types for the vtable stub generator was generic on a type
Tto represent a type key. TheTtypes were required to match between the two interfaces. This mechanism was designed to enable each native API platform to provide their own casting key, for exampleIIDs in COM, without interfering with each other or requiring using reflection-based types likeSystem.Type.However, practical implementation showed that providing just a "type key" was not enough information to cover any non-trivial scenarios (like COM) efficiently without effectively forcing a two-level lookup model or hard-coding type support in the
IUnmanagedVirtualMethodTableProvider<T>implementation. Additionally, we determined that using reflection to get to attributes is considered "okay" and using generic attributes would enable APIs that build on this model like COM to effectively retrieve information from theSystem.Typeinstance without causing additional problems.