-
Notifications
You must be signed in to change notification settings - Fork 113
Add technical docs on generic interfaces codegen #1989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: fhl/cswinrt-3.0
Are you sure you want to change the base?
Add technical docs on generic interfaces codegen #1989
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Posting my comments but I got a little lost in this writeup so I think we need an in-person review of some of this if you want thoughtful feedback.
|
||
This type derives from `WindowsRuntimeObject`, which provides all the usual support for IDIC, generated COM interfaces, and more. If needed, these RCW types (one per generic interface) can also contain additional state necessary to properly map the Windows Runtime interface behavior to the managed one. This is the case for `IEnumerator<T>`, which is slightly different than `IIterator<T>`, for instance. | ||
|
||
Next, an interface is needed for each "Methods" implementation, for each generic interface. For `IIterator<T>`, it looks like this: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was mostly with you until this point. "An interface is needed" -- why? How does this connect to the scenarios above? I assume there's some general-purpose C#/WinRT machinery that is trying to reach out for this, but when/where?
} | ||
``` | ||
|
||
This is conceptually similar to `IWindowsRuntimeComWrappersCallback` (which is used for delegates and sealed runtime class names), with the main difference being that it is specialized for unsealed types (and interfaces). In this case, implementations need to know the runtime class name of the native object, to determine whether they can marshal it via the fast path using a statically visible RCW type (see below), or whether they should fallback to the logic to marshal arbitrary opaque object that is used when no static type information is available (which involves going through the interop type lookup to get the marshalling info, etc.). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretend I don't know anything about the current C#/WinRT implementation in this regard. What do I need to know/care about to evaluate this proposal? :)
This PR adds docs explaining in detail all codegen to handle generic collection interfaces in CsWinRT 3.0.