-
Notifications
You must be signed in to change notification settings - Fork 512
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
Expose low-level building blocks as API #12140
Comments
There's no reason you can't write this code yourself, or even copy our code. We've documented this, with some helper code you can copy: https://docs.microsoft.com/en-us/xamarin/ios/internals/objective-c-selectors#creating-your-own-signatures
There's a reason for this: there's a lot of them, and they're generated. Every function signature needs a different P/Invoke, and it ends up being a pretty big list. In the early days of MonoTouch these P/Invokes were public, but it turned out a nightmare to maintain, because as we changed implementation details, the set of generated P/Invokes changed, and suddenly we were unintentionally breaking the API, and we had to copy the missing generated P/Invokes to manually written code, and rinse and repeat for quite a few releases. |
Duplicating the code does not make much sense - JITing twice, different assemblies, etc. It would probably be okay to have it as a non-supported API, as in, have a way to reference that dll as a |
At that point it might just as well be shipped differently (NuGet for instance). |
Another possible impl would be source generation similar to dotnet/pinvoke#565 |
I am not sold on the idea of these being public even if they get versioned in NuGet, as @rolfbjarne mentioned things change on each release and if people get stuck or another package depends on a specific one because things changed and there are members that are no longer available but the latest SDK depends on the latest version because of new p/invokes are required it gets really hairy and painful really fast. The source generator idea is not bad but I think at this point is not in the scope of .NET 6 |
We have discussed this idea further and we all agreed on not being in the scope of the project, if you need any p/invokes these should live and be maintained in the project that needs them. |
Steps to Reproduce
Expected Behavior
Users of Xamarin.Mac should have some way to use the low-level APIs (maybe in some Unsafe namespace?)
That way, someone could technically write their own variation of bindings for performance improvements (avoiding marshalling between NSString <-> string for
string
bound APIs that have to marshal to NSString in native).The APIs in question would be: selector constants, messaging API and Pinvoke definitions.
Actual Behavior
They're all internal/private
The text was updated successfully, but these errors were encountered: