Skip to content
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

Add statically checked access to other interfaces #32

Open
Boddlnagg opened this issue Feb 25, 2017 · 3 comments
Open

Add statically checked access to other interfaces #32

Boddlnagg opened this issue Feb 25, 2017 · 3 comments

Comments

@Boddlnagg
Copy link
Collaborator

Boddlnagg commented Feb 25, 2017

Many classes implement other interfaces besides their main interface. For example, Windows.System.LauncherOptions implements ILauncherOptions, but also ILauncherViewOptions, ILauncherOptions2 and ILauncherOptions3. QueryInterface can be used to get implementations of these other interfaces, but can generally query arbitrary interfaces and might fail if the interface is not actually available, therefore it returns Result<>. We should add a way to query those interfaces that are known to be valid (from the metadata), which can then be returned directly.

Maybe this could make use of Rust's conversion traits. Ideally it could work automatically, so that an instance of ComPtr<LauncherOptions>, which allows calls to methods defined on ILauncherOptions through deref, could also allow calls to methods defined on the other interfaces.

@Boddlnagg
Copy link
Collaborator Author

Boddlnagg commented Feb 27, 2017

How this is done in the modern C++ projection is nicely explained in https://www.youtube.com/watch?v=lm4IwfiJ3EU#t=31m40s

@Boddlnagg
Copy link
Collaborator Author

Another point to consider: Versioned interfaces such as ILauncherOptions2 and ILauncherOptions3 are added in newer releases, when only ILauncherOption exists originally. This means that a newer SDK will know these interfaces while an older SDK doesn't. When we check in the generated code as part of the crate, we always build with the SDK that is installed on the build machine, not the one that is installed on the user machine. So there might be interfaces in the generated code that do not yet exist on the OS of the user of the crate. In such cases, QueryInterface will return an error and we must not wrap it in such a way that these kinds of errors get lost.

@Boddlnagg
Copy link
Collaborator Author

Parent interfaces (and the main interface of classes) work through Deref, for other interfaces we probably need Into/From.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant