-
Notifications
You must be signed in to change notification settings - Fork 40
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 support for CoreFoundation
-like libraries
#556
Comments
Related: How should casting / "toll-free bridging" between Objective-C and CoreFoundation-like types work? |
CoreFoundation
-like librariesCoreFoundation
-like libraries
Hi! Thanks for starting such a sub-project. I am indeed looking to use However, the dependency graph runs somewhat deep. From what I could gather by rashly
I am definitely ready to help in achieving all of this, as it is a fundamental (pun intended) requirement of the project I have recently started. I have for example started fiddling with |
Frameworks that consist of Objective-C classes usually only depend on CoreFoundation-like libraries in very few places, so we can get a lot of the way there by just skipping over those, I've done so for NetworkExtensions in e507a74 (the only manually authored file in that commit was What I mostly need help with in this issue is figuring out the rules for how methods taking and giving pointers to |
(I'm aware that the difference between e.g. CoreFoundation and NetworkExtension must feel a bit arbitrary to the uninitiated, but it basically boils down to whether the framework uses Objective-C classes or not (because if it does, then it's likely to be written in a way that |
Yeah, I saw that there was this possibility, but I didn't exactly know what I needed from
Yes, I can see that, thank you! However, I see that
Yes, I was able to get that going too. I think I should be able to port |
If you do end up needing it, you can always write a manual binding using
I think Network is closer to CoreFoundation in nature, it has it's own |
Note: I just read that Swift considers core-foundation types as root objects. So we'll have to ensure that they work with the things that we (currently) expect root objects to work with (like weak, and possibly Also, Swift seems to retain and release these with |
CoreFoundation
,CoreServices
and similar frameworks have memory management properties that I'm yet unsure of how we should handle.Should we introduce a new wrapper type, similar to
Id
? Or should they manage it internally?Prior art:
fruity
core-foundationr
and familyThe text was updated successfully, but these errors were encountered: